On 2011-11-23, at 04:51 , Stephen J. Turnbull wrote: > Xavier Morel writes: >> On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote: >>> Barry Warsaw writes: > >>>> Hopefully, we're going to be making a dent in that in the next version of >>>> Ubuntu. > >>> This is still a big mess in Gentoo and MacPorts, though. MacPorts >>> hasn't done anything about ceating a transition infrastructure AFAICT. > >> What kind of "transition infrastructure" would it need? It's definitely >> not going to replace the Apple-provided Python out of the box, so >> setting `python` to a python3 is not going to happen. > > Sure, but many things do shadow Apple-provided software if you set > PATH=/opt/local/bin:$PATH. > Some I'm sure do, but "many" is more doubtful, and I have not seen any do that in the Python ecosystem: macports definitely won't install a bare (unversioned) `python` without the user asking.
> I'm not sure what infrastructure is required, but I can't really see > MacPorts volunteers doing a 100% conversion the way that Ubuntu's paid > developers can. So there will be a long transition period, and I > wouldn't be surprised if multiple versions of Python 2 and multiple > versions of Python 3 will typically need to be simultaneously > available to different ports. That's already the case so it's not much of a change. > >> It doesn't define a `python3`, so maybe that? > A python3 symlink or script would help a little bit, but I don't think > that's necessary or sufficient, because ports already can and do > depend on Python x.y, not just Python x. Yes indeed, which is why I was wondering in the first place: other distributions are described as "fine" because they have separate Python2 and Python3 stacks, macports has a Python stack *per Python version* so why would it be more problematic when it should have even less conflicts? >> Macports provide `port select` which I believe has the same function >> (you need to install the `python_select` for it to be configured for >> the Python group), the syntax is port `select --set python $VERSION`: > > Sure. > > I haven't had the nerve to do this on MacPorts because "port" is such > a flaky thing (not so much port itself, but so many ports assume that > the port maintainer's local configuration is what others' systems use, > so I stay as vanilla as possible -- I rather doubt that many ports are > ready for Python 3, and I'm not willing to be a guinea pig). That is what I'd expect as well, I was just giving the corresponding tool to the gentoo version thereof. > The problem that I've run into with Gentoo is that *even when the > ebuild is prepared for Python 3* assumptions about the Python current > when the ebuild is installed/upgraded gets baked into the installation > (eg, print statement vs. print function), but some of the support > scripts just call "python" or something like that. OTOH, a few > ebuilds don't support Python 3 (or in a ebuild that nominally supports > Python 3, upstream does something perfectly reasonable for Python 2 > like assume that Latin-1 characters are acceptable in a ChangeLog, and > the ebuild maintainer doesn't test under Python 3 so it slips through) > so I have to do an eselect dance while emerging ... and in the > meantime things that expect Python 3 as the system Python break. > > So far, in Gentoo I've always been able to wiggle out of such problems > by doing the eselect dance two or three times with the ebuild that is > outdated, and then a couple of principal prerequisites or dependencies > at most. > > Given my experience with MacPorts I *very much* expect similar > issues with its ports. Yes I would as well, although: 1. A bare `python` call would always call into the Apple-provided Python, this has no reason to change so ports doing that should not be affected 2. Few ports should use Python (therefore assume things about Python) in their configuration/installation section (outside upstream's own assumptions): ports are tcl, not bash, so there shouldn't be too much reason to call Python from them _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com