[PyQt] SIP v5 Roadmap

[Phil Thompson]

On Sun, 28 Nov 2010 18:26:58 +0100, Giovanni Bajo <rasky at develer.com>
wrote:
> On dom, 2010-11-28 at 15:12 +0000, Phil Thompson wrote:
>> On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo <rasky at develer.com>
>> wrote:
>> > On lun, 2010-11-22 at 16:06 +0000, Phil Thompson wrote:
>> >> I've added a roadmap for SIP v5 at...
>> >> 
>> >> http://www.riverbankcomputing.com/software/sip/roadmap
>> >> 
>> >> Comments welcome.
>> > 
>> > Hi,
>> > 
>> > I'm concerned by this:
>> > 
>> > ====================================================================
>> > The code generator will be reimplemented using Python v3. It will be
>> > able to be used as a standalone application or a package.
>> > ====================================================================
>> > 
>> > This means that users of SIP will need to install Python v3 as a
>> > dependency to run sip, even for projects using Python v2. Additional
>> > build dependencies can really really be painful to handle.
>> > 
>> > I suggest you revisit this, unless you plan to make it work with
Python
>> > v2 through 3to2 or similar. An alternative option would be to write
it
>> > in 2to3-friendly dialect of Python v2, so that in the future when you
>> > are ready to drop Python 2 support you can simply drop the original
v2
>> > source code and use the generated version as new basis for
development.
>> 
>> I don't see the dependency as a problem. There is no problem installing
>> Python v2 and v3 side by side on Windows. Linux distros have been
>> packaging
>> Python v3 to run alongside v2 for some time.
> 
> Multiply that for different projects running different Python versions,
> requiring different SIP/PyQt versions, maybe different C++ compilers,
> and now different Python3 versions.
> 
> Your statement is true for the simplest setups. I help people building
> stuff as part of my job (yes, it can be a job in itself :), and any
> additional dependency can cause problems, make the build system harder,
> and cause unnecessary slowdown in development.
> 
> There are already strong dependencies between sip versions, Python
> versions and PyQt versions (and I'm ignoring Visual Studio issues,
> PyInstaller issues, build system issues, and whatnot), and I fear what
> might happen if we add another additional and incompatible Python
> version to the picture.
> 
> As a concrete example, I'm working right now on an internal one-file
> custom build of Python bundled with sip/PyQt (+ other modules) as
> builtins, and a import hook to import sip modules (= they get
> transparently recompiled, much like pyximport does for Cython); by
> adding Python3 to the picture, one would need this internal Python build
> to ship with a Python3 within it.
> 
> Now that I think of it, this might be less of a problem for me if SIP4
> and SIP5 work together at the binary level. For instance, will it be
> possible to build PyQt4 with SIP5 and PyQwt with SIP4, and import them
> within the same process, pass objects back and forth, etc.? In this
> case, I could keep on using SIP4 wherever I feel like SIP5 would
> complicate build environments too much.

That would work only until SIP5 needed to bump the major number of the
internal API.

Of course the whole point of producing the roadmap and a migration plan
for SIP4 to SIP5 is to make it easy for things like PyQwt to move from one
to another in their own time.

If you are suggesting that SIP5 should be implemented in Python2 rather
than Python3 then you are just creating the same "problem" for a different
sub-set of users. You are also expecting me to write new software in a
"dead" language.

I have no problem in producing a Python2 version if it turns out to be
easy to do. I had no intention of supporting Python2 with dip, but it
turned out to be easy to support Python v2.6 with some simple patches.
However I'm not going to specify it as a requirement and I don't want
people to get the impression that it will definitely happen.

Phil