[PyQt] Experimental PyQt5 v5.6 Wheels Available

[Phil Thompson]

On 9 Apr 2016, at 6:37 pm, Detlev Offenbach <detlev at die-offenbachs.de> wrote:
> 
> Hi Phil,
>  
> On Saturday 09 April 2016, 17:49:53 Phil Thompson wrote:
> > I've created wheels for SIP and PyQt5 v5.6 snapshots that are available from
> > their respective download pages. They are for the following architectures:
> > 
> > Linux 64-bits
> > OS X 64-bits
> > Windows 64-bits
> > Windows 32-bits
> > 
> > The PyQt5 wheels contain a minimal copy of Qt v5.6 - only those parts needed
> > to support PyQt.
>  
> What does this mean in particular? How do you define 'minimal copy of Qt v5.6?

So that all the imports work, and the expected plugins are present.

> > They include pyuic5 but not (yet) pyrcc5 and pylupdate5.
> > They do not contain QScintilla - there will be separate wheels for that.
>  
> Why not have a complete wheel including QScintilla? I could envisage people trying to install eric having forgotten to install the QScintilla wheel beforehand. This will probably happen on Windows because the current installer is self contained.

The eric wheel would specify the QScintilla wheel as a dependency and it would get installed automatically.
 
> > Please give feedback.
> > 
> > I'm particularly interested in how well the Linux wheel works across
> > different Linux distros. They were created on Ubuntu.
> > 
> > The wheels have not been uploaded to PyPi because the PyQt wheels are too
> > large, which is a shame. My original plan was to *not* bundle Qt. However
> > that means that PyQt has to make assumptions about where Qt has been
> > installed. The only reasonable assumption is the default location used by
> > the Qt installers (ie. ~/Qt5.6.0 on Linux
>  
> The default path on Linux seems to be ~/Qt/5.6 if the online installer is used and ~/Qt5.6.0 if the offline installer is used. The installers are really tricky and seem to have a few glitches.
>  
> > and OS X and C:\Qt\Qt5.6.0 on
> > Windows). I thought that was going to be too restrictive.
> > 
> > I'd like feedback on the best approach to this...
> > 
> > 1. Stick with the current approach, unable to use PyPi, large download,
> > simple install once downloaded, supports non-default Qt locations.
> > 
> > 2. Don't bundle Qt, can use PyPi, small download, simple install, Qt must be
> > installed in its default location.
> > 
> > I could supplement 2) with a tool (provided as part of the wheel) that could
> > be run (once) to "re-direct" the installed PyQt to the actual Qt
> > installation.
>  
> Would prefer this approach with the tool being executed as part of the wheel installation. It should try to determine the Qt path automatically and ask the user as a last resort.

Wheels don't work like that. You can't specify something that runs post installation.
 
> > A further variation would be a separate tool that would modify the
> > downloaded wheel to do the re-direct so that the modified wheel would be
> > correct for your personal/company standards for the Qt location.
>  
> Using a tool to modify the wheel could mean to use a newer PyQt with an older Qt (e.g. PyQt 5.7 with Qt 5.6)?

No. Qt compatibility doesn't work in that direction.

Phil