Re: How to build pyqt sources to provide the same content than official wheel?

>
> I don't see why it should be unusable. It will be the full installation
> (a wheel is a subset), use your existing Qt installation and can still
> be uninstalled with pip.
>

Ok, maybe unusable hasn't been a good word (sorry about my English btw),
what I meant is
the artifacts produced by nmake install are a very small subset from the
artifacts produced
by the official pypi wheel, compare both:

* Content produced by pyqt sources:
https://dl.dropboxusercontent.com/s/nxhzst7f9ajtd3n/2019-07-20_14-10-42.txt
* Content produced by pypi wheel:
https://dl.dropboxusercontent.com/s/kqbbeu6wsnx0s4z/2019-07-20_14-10-48.txt

You can see there are a lot of missing submodules (pyd), also sip.pyd is
missing and basically the Qt folder also missing...
in addition, there are a lot of non-required sip files installed in the
virtual env.

So, is this because the way I've compiled pyqt from sources is not
complete? or is it because after installing pyqt from sources I'm also
required to do some extra manual steps...? What do you mean by "use your
existing Qt installation"? copying it manually to the virtualenv?


> That depends on when the fixed version of Qt is released.
>

Actually, that's another question I'd like to ask you, what do you mean by
"fixed version of Qt is released"?
When developing pyqt, are you just using official packages from here
https://download.qt.io/archive/qt/
instead building yourself the Qt repos at some specific commit hash?


> sip5 implements a new build system that supports PEP517. This is
> finished (apart from the docs) and is just being tweaked to support
> PyQt5's new build system (which is currently being written). This might
> sound a lot of work but is mostly a refactoring of those internal tools
> I mentioned earlier that I've been using for years.
>
> PyQt5's new build system will also include a tool that will allow you to
> update a wheel with a new version of Qt.
>
> ETA for sip5 is between 1 and 2 months.
>

Wow, this sounds extremely awesome, really looking forward to it!

I must to say in the past years I've avoided building pyqt from sources
because I've always found it a
really complex non-standard python process, it's always looked to me like
the type of deployment
that works really way for the maintainer but not so well for the
users/customers. Said otherwise,
pyqt & sip are both amazing piece of technologies but the deployment
process looks to me like a bit obscure.
Which on the other hand, makes sense as the existing tools to create c++
wrappers packages have never been ideal.
I've got myself a bunch of custom tools to create swig wrapper that don't
follow the best python
packaging practices neither but they work "for me" :/

_______________________________________________
PyQt mailing list    [email protected]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt