CentOS 8 nodes available now
fungi at yuggoth.org
Wed Oct 16 02:43:40 UTC 2019
On 2019-10-16 01:35:48 +0100 (+0100), Sean Mooney wrote:
> i would personally prefer to have /usr/bin/python ->
> linux distros seem to be a bit split on this i belive arch and
> maybe debian (i saw on of the other majory disto families adopt
> the same apparch) link python to python3
Debian definitely does not. The current plan for when Debian stops
shipping Python 2.7 is that it will have no /usr/bin/python
installed. The unversioned /usr/bin/python is and has long been an
interpreter for the Python 2 language. Python 3 is a different
language, and its interpreter should not by default assume the
command name of the Python 2 interpreter. I think Arch Linux made a
huge mistake in pretending they were the same thing, and sincerely
hope no other distribution does the same.
> i think /usr/bin/python should map to /usr/bin/python3 and you
> should assume that it now python3.
I think that's a disaster waiting to happen.
> if you dont do that hen every script that has ever been writtne or
> packaged needs to be updated to reference python3 explictly.
Yep, that has to happen anyway in most cases to address Python 2 vs
3 language compatibility differences. Being explicit about which
language a script is written in is a good thing.
> there were much fewer user of python1 when that tansition happened
> but python became a link to the default systme python and
> eventully pointed to python2 i think we should continue to do that
> and after a decase of deprecating python2 we should reclaim the
> python symlink and point it to python3
The language did not change in significantly backward-incompatible
ways with 2.0. On the other hand "Python 3000" (3.0) was essentially
meant as a redesign of the language where backward-incompatibility
was a tool to abandon broken paradigms. It's possible to write
software which will run under both interpreters (and we have in
fact, rather a lot even), but random scripts written for Python 2
without concerns with forward-compatibility usually won't work on a
Python 3 interpreter.
> well from a devstack point of view we almost exclucive install
> form pip so installing python packages form the disto is the anti
> pattern not installing form pip. that said we shoudl consider
> moving devstack to use --user at somepoint.
It's hard not to call https://review.openstack.org/562884 an
anti-pattern. The pip maintainers these days basically don't want to
have to continue supporting system-context installs, as responses on
https://github.com/pypa/pip/issues/4805 clearly demonstrate.
DevStack's been working around that for a year and a half now, as
have our image builds (until Ian's efforts to stop doing that for
the centos-8 images). Yes doing --user or venv installs is likely
the core of the solution for DevStack but it needs more folks
actually working to make it happen, and the ugly hack has been in
place for so long I have doubts we'll see a major overhaul like that
any time soon.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 963 bytes
Desc: not available
More information about the openstack-discuss