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<baz...@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 _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt