On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will* break external tools
that attempt to locate the python executable from an installed
directory. However, I'm not sure this requirement exists for virtual
environments - such tools probably will not attempt to locate the
executable in a virtual env as there is no standard place for a virtual
env to live.
So having a standard layout in the virtual envs still seems a win - we
keep the inconsistency in the layout of the "installed" Python, but
tools which work with virtualenvs still get a standardized layout.
[At least I think that is your proposal - can you confirm that the
directory layouts in your proposal exactly match the directory layouts
in virtual envs on all other platforms? ie, that inconsistencies like
the python{py_version_short} suffix will not remain?]
Just to be completely clear, my current concern is only with the
location of the executable in an installed Python.
The fact is that most code doesn't know about this, only installers or
virtual environments. Most code just assumes that distutils does its
thing correctly and that binaries are installed... wherever the binaries
go.
Of course - but this raises 2 points:
* I'm referring to *external* tools that launch Python. They obviously
need to know where the binaries are to launch them. Eg, the PEP397
launcher; the (admittedly few) people who use the launcher would need to
upgrade it to work under your scheme. Ditto *all* other such tools that
locate and launch Python.
* "most code" isn't a high enough bar. If we only considered such
anecdotes, most backwards compatibility concerns would be moot.
Again, I have experience with this, as I have edited my own install to
do this for a couple of years. The breakage is minimal and it makes
things much more consistent and easier to use for cross-platform
development.
All due respect, but I'm not sure that is a large enough sample to draw
any conclusions from. I've offered 2 concrete examples of things that
*will* break and I haven't looked for others.
Also, I'm still yet to see what exactly becomes "easier" in your model?
As you mention, most Python code will not care; distutils and other
parts of the stdlib will "do the right thing" - and indeed, already do
for Windows. So the proposal wants to change distutils and other parts
of the stdlib even though "most code" won't notice. But the code that
will notice will be broken!
So I dispute it is "easier" for anyone; I agree it is more consistent,
but given the *certainty* external tools will break, I refer to you the
Zen of Python's thoughts on consistency ;)
Right now we are in front of the knee on major 3.x adoption - I would
like to have things be standardized going forth everywhere.
It is a shame this wasn't done as part of py3k in the first place. But
I assume you would be looking at Python 3.4 for this, right? So if
people start working with Python 3.3 now and finds this change in 3.4,
we are still asking them to take the burden of supporting the multiple
locations. I guess I'd be less concerned if we managed to get it into
3.3 and also recommended to people that they should ignore 3.2 and
earlier when porting their tools/libraries to 3.x.
I think I've made all the points I can make in this discussion. As I
mentioned at the start, I'm not quite -1 on the idea, so I'm not going
to push this barrow any further (although I'm obviously happy to clarify
anything I've said...)
Cheers,
Mark
_______________________________________________
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
