work-in-progress: python-3.0rc1
Hi, Attached is a work-in-progress port of Python-3.0rc1. It builds, packages and runs on i386 (at least), but at least one regress test hangs. You will need to be running fairly -current for this - a few bugs in libc and elsewhere were shown up by the python regress tests (and subsequently fixed). Python-3.x deliberately breaks compatibility with the 2.x series, so I am packaging this as "python3-3.0rc1" under a new lang/python3 directory. This isn't final, because I need to think about how it will work with python libraries elsewhere in ports - over time, it is expected that many will support both python-2.x and python-3.x. The choice is to maintain separate py3-* versions, or to unify. How we deal with python libraries needs work anyway - it would be much nicer if we could parallel install the same library targetted at different python versions and have the package system play nice. Python supports this fine but unfortunately I haven't figured out the right incantations to support it cleanly in ports. Feedback welcome. -d python3.tgz Description: Binary data
Re: work-in-progress: python-3.0rc1
How we deal with python libraries needs work anyway - it would be much nicer if we could parallel install the same library targetted at different python versions and have the package system play nice. Python supports this fine but unfortunately I haven't figured out the right incantations to support it cleanly in ports. I was just thinking this a few days ago when working on a py-django update and trying to make it work with 2.6. Maybe look at what Kurt did for Java with the javaPathHelper program, but like you I'm not sure how to translate this into Python, where there is almost always a shebang like "#!/usr/bin/env python" to get the script started.
Re: work-in-progress: python-3.0rc1
Just built it on i386. Will run it for a few weeks and see what we come up with. Thanks! Brandon On Sun, Oct 19, 2008 at 7:53 PM, Ian Darwin <[EMAIL PROTECTED]> wrote: > > How we deal with python libraries needs work anyway - it would be >> much nicer if we could parallel install the same library targetted at >> different python versions and have the package system play nice. Python >> supports this fine but unfortunately I haven't figured out the right >> incantations to support it cleanly in ports. >> > > I was just thinking this a few days ago when working on a py-django update > and trying to make it work with 2.6. Maybe look at what Kurt did for Java > with the javaPathHelper program, but like you I'm not sure how to translate > this into Python, where there is almost always a shebang like > "#!/usr/bin/env python" to get the script started. > >
Re: work-in-progress: python-3.0rc1
On Sun, 19 Oct 2008, Ian Darwin wrote: > > > How we deal with python libraries needs work anyway - it would be > > much nicer if we could parallel install the same library targetted > > at different python versions and have the package system play nice. > > Python supports this fine but unfortunately I haven't figured out > > the right incantations to support it cleanly in ports. > > I was just thinking this a few days ago when working on a py-django > update and trying to make it work with 2.6. Maybe look at what Kurt > did for Java with the javaPathHelper program, but like you I'm not > sure how to translate this into Python, where there is almost always a > shebang like "#!/usr/bin/env python" to get the script started. The problem isn't scripts so much as library coexistence - I'd like to be able to install (say) ports/graphics/py-Imaging for both python-2.5 and python-2.6, e.g. as py-Imaging-1.1.6-py25 and py-Imaging-1.1.6-py26. Python does the right thing and ensures that all the files end up non- conflicting directories, but there needs to be some infrastructure in bsd.python.mk to get the versioning and conflict avoidance right. I posted some patches to bsd.python.mk that started to get the versioning bit right a while back, but they never addressed the conflicts and I never got any feedback. -d
Re: work-in-progress: python-3.0rc1
* Damien Miller wrote: > Hi, > > Attached is a work-in-progress port of Python-3.0rc1. It builds, > packages and runs on i386 (at least), but at least one regress test > hangs. You will need to be running fairly -current for this - a few bugs > in libc and elsewhere were shown up by the python regress tests (and > subsequently fixed). > > Python-3.x deliberately breaks compatibility with the 2.x series, > so I am packaging this as "python3-3.0rc1" under a new lang/python3 > directory. This isn't final, because I need to think about how it > will work with python libraries elsewhere in ports - over time, it is > expected that many will support both python-2.x and python-3.x. The > choice is to maintain separate py3-* versions, or to unify. > > How we deal with python libraries needs work anyway - it would be > much nicer if we could parallel install the same library targetted at > different python versions and have the package system play nice. Python > supports this fine but unfortunately I haven't figured out the right > incantations to support it cleanly in ports. at the moment we use a flavor fir this (namely for several python ports that used in zope environments and thus require python2.4). I am still contending that having the version in the name stem would be the best solution: instead of py-whatever (for the current default python) and py-whatever-python24 (for python2.4) it would be py25-whatever, py24-whatever and be very explicit about the version. Such packages would not need to be changed if the "default" python changes, unlike in our current situation where the py-whatever package would need to be changed to install in a different location. > > Feedback welcome. > > -d
Re: work-in-progress: python-3.0rc1
On Mon, Oct 20, 2008 at 08:10:52AM +0200, Marc Balmer wrote:
> I am still contending that having the version in the name stem
> would be the best solution: instead of py-whatever (for the
> current default python) and py-whatever-python24 (for python2.4)
> it would be py25-whatever, py24-whatever and be very explicit
> about the version.
+1; I think this is the most sane approach.
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*-[ BSD: Live Free or Die ]*
Re: work-in-progress: python-3.0rc1
On Mon, 20 Oct 2008, Will Maier wrote: > +1; I think this is the most sane approach. +2 -- Antoine
Re: work-in-progress: python-3.0rc1
hmm, on Mon, Oct 20, 2008 at 08:10:52AM +0200, Marc Balmer said that > I am still contending that having the version in the name stem would > be the best solution: instead of py-whatever (for the current default > python) and py-whatever-python24 (for python2.4) it would be py25-whatever, > py24-whatever and be very explicit about the version. what about stuff that works with more (any) python version(s)? -f -- questions, questions! does it ever end?!
Re: work-in-progress: python-3.0rc1
* frantisek holop wrote: > hmm, on Mon, Oct 20, 2008 at 08:10:52AM +0200, Marc Balmer said that > > I am still contending that having the version in the name stem would > > be the best solution: instead of py-whatever (for the current default > > python) and py-whatever-python24 (for python2.4) it would be py25-whatever, > > py24-whatever and be very explicit about the version. > > what about stuff that works with more (any) python version(s)? of course a package would be built for _every_ python version. > > -f > -- > questions, questions! does it ever end?! >
