[PyQt] Detecting which Python version is used by SIP and PyQt

[Hans-Peter Jansen]

On Saturday 23 October 2010, 22:35:36 Baz Walter wrote:
> On 23/10/10 20:04, Hans-Peter Jansen wrote:
> > On Saturday 23 October 2010, 19:28:34 Baz Walter wrote:
> >> On 23/10/10 18:07, Phil Thompson wrote:
> >>> On Sat, 23 Oct 2010 17:39:28 +0100, Baz Walter<bazwal at ftml.net>
> >
> > wrote:
> >>>> On 23/10/10 12:25, Hans-Peter Jansen wrote:
> >>>>> On Saturday 23 October 2010, 02:54:40 Xavion wrote:
> >>>>>> Doing so will save me from having to hard-code something like
> >>>>>> "#!/usr/bin/env python2" into the main executable file, only
> >>>>>> to be disappointed after finding out that some Linux
> >>>>>> distributions have already built PyQt on Python v3.
> >>>>>
> >>>>> For a transition phase of a couple of years, I would do it the
> >>>>> other way around. Your distribution should have created a
> >>>>> python3 symlink, hence, if you code for python3, use
> >>>>> #!/usr/bin/env python3, given it isn't compatible with python< 
> >>>>>   3, otherwise use #!/usr/bin/env python.
> >>>>
> >>>> not sure i understand you here. the current situation on arch
> >>>> is:
> >>>>
> >>>>        python ->   python3.1
> >>>
> >>> That is unbelievably dumb.
> >>
> >> that was exactly my initial reaction. however, given arch's
> >> philosophy, it does make sense.
> >
> > No idea, how this move could be labeled philosophy, since it is
> > going to break nearly every 3rd party python software out there. In
> > the end it only contributes to arch users isolation as it will
> > always take arch specific patches to get legacy code working. No
> > sane distribution will follow this pattern.
>
> that's an extreme over-reaction - but if you are unsure how things
> work on arch, it is perhaps understandable.

I don't wanted to sound that harsh, but "can do" is not a synonym 
for "should do". Technically, we always have to manage increasing 
diversification, especially at the packaging front. And because I do 
fight in this area, I'm biased.

> let me try to shed a little light on this.
>
> arch is a rolling-release distro. updates are very frequent and
> generally tend include the very latest, "bleeding-edge" versions.
>
> when arch made the transition to python3, about 600 python-related
> packages were updated in the process. these were all pre-complied
> binary packages that are officially supported by the arch development
> team.
>
> in addition to the repositories of supported packages, arch has an
> unofficial repostitory maintained by the community. this consists of
> build scripts which use arch's automated build system to install
> unsupported, third-party software. the build system will resolve all
> dependencies (using the same package management tools as the
> supported packages), and then download, build and install the
> software from source using the build scripts. this means that all
> installed software on the system is handled by a single package
> management system. most arch users will therefore actively avoid any
> do-it-yourself installation of third-party software. if there is no
> unofficial package currently available, they will either create it
> themselves, or make a request for one.
>
> i hope this makes it obvious that any fears about breaking "nearly
> every 3rd party python software out there" are completely unfounded.
> when arch users made the update which included the transition to
> python3 a few days ago, the only things that broke were a handful of
> unofficial packages and some scripts that users created themselves.
>
> > I'm really sorry to have answered to this thread without
> > understanding the full scope, and therefore even contributed to the
> > confusion.
> >
> > As a consequence, I'm going to ignore each and every arch linux
> > python compatibility issue, that may arise here.
>
> such remarks are totally uncalled for (and, with respect, unworthy of
> you).
>
> arch has been around for quite a while now and has a growing
> community of very loyal users. it may do some things very
> differently, but at the end of the day, it's just another linux
> distro.

This is exactly the point. I have a hard time to understand such - in my 
view unnecessary - single handed efforts to solve an issue in an  
unusual manner.

Anyway, Baz, given, that you like arch and most probably using it also, 
and I do respect you as a highly qualified PyQt contributor, whose 
contributions are a pleasure to read, let's forget about this now. 
We're not going to change anything from here..

I might occasionally ask you, how arch "danger seeker" linux ;-) solve 
things, e.g. does arch solve the problem of:

coexisting 32 bit and 64 bit builds of a 2.x and 3.x python version, 
respecting noarch elements, with including PyQt in a way, that it's 
possible to develop and test sip extensions for all targets. 

I'm _slowly_ approaching this now, and it is really _tough_, but maybe 
rpm's weapons (including me) are just blunt.

See, such issues make me fight for solutions of common sense.

Cheers,
Pete