Open Stack

TL;DR ok the way the image will work makes sense :)
all i really care about is /usr/bin/python should not be
a symlink to /usr/bin/python2 on python3 "only" distors
to ensure we dont execute code under python 2 by mistake.

On Wed, 2019-10-16 at 02:43 +0000, Jeremy Stanley wrote:
> On 2019-10-16 01:35:48 +0100 (+0100), Sean Mooney wrote:
> [...]
> > i would personally prefer to have /usr/bin/python ->
> > /user/bin/python3
> > 
> > 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.
perhaps though i would argue that the code name of the python2 interperatr
was always python2 or python2.7 no python. python was the name of system python
the fact that they happen to be the same thin was a historical acident fo rthe last
decade but if i exend your argument then we never should have had
#!/usr/bin/python at all as a script entry point which in hindsight may have been correct.
https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors
allow effectivly all of the possible options so there is no wrong answer just different
tradeoffs.

> 
> > 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.
perhaps the only thin i hope we really avoid going forward is a python
that maps to python2 that silntly allows things to work when we think
we are running python 3 only. e.g. i prefer spipts that can run under
python3 sliently doing so then over silently running on python2.
if on python3 systems distro ensure that python does not map to python2
even when python 2 is installed unless the system admin expcitly sets up the symlink
i guess that acive the same goal. it seams that is the path debain an rhel are taking
e.g. dont provide "python" via packages so that it is only created if the sytem admin
creates it.
> 
> > 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.
i guess but it feels kind of sad to say that forever we will have to type
python3 in stead of python just because legacy script coudl break. i woudl prefer
them to break and have the convinece. the is partly because most python2 i have
encounterd has been vaild python3 but i know that that was not the case for
alot of scripts.
> 
> > 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. 
i ment when using devstack prefering distro pacagke over pip would be
an anti patteren as part of the reason we install form pip in the first
place is to normalise the install so that it is contolled and as similar
as possible beteen distors. the fact we have to do that in devstack ya does
feel like a hack i was not aware we did that.
> 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.
yep i was just trying to suggest that we shoudl avoid installing the disto
version and basicaly only install the interpreter form the distro to avoid
mixing packages as much as possible.
> 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
i do think its worth revisiting devstack venv install capablity at some point
i know its there but have never really used it but hte fact that devstack
installs but the requirement.txt and test-requriement.txt gloablly has caused issue in
the past. i tried to remove install the test-requirement.txt in the past but some jobs
depend on that to install optional packages so we cant.
>  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.
well the main thing that motivated me to even comment on this thread
was the fact we currently have a  hack that with lib_from_git where if you enable
python 3 i will install the lib under python 2 and python3. the problem is the 
interperter line at the top of the entry point will be replaced with the python2 version
due to the order of installs. so if you use libs_form _git with nova or with a lib that provides
a setup tools console script entrypoint you can get into a situation where your python 3 only
build can end up trying to run "python2" scripts. this has lead to some interesting
errors to debug in the past. anyway i was looking forward to having a python3 only disto
to not have to deal with that in the future with it looks like