On 15/03/2012 3:03 AM, Lindberg, Van wrote:
On 3/14/2012 1:32 AM, Mark Hammond wrote:
As per comments later in the thread, I'm -1 on including
"python{py_version_short}" in the lib directories for a number of
reasons; one further reason not outlined is that it would potentially
make running Python directly from a built tree difficult. For the same
reason, I'm also -1 on having that in the include dir.
A built tree would look the same as always - the directories would only
be moved (if at all) during installation. Thus, you will still be able
to run python directly from a built installation.
So long as the location of the "lib" dir doesn't change, that is
probably true. If lib was to change though, then PC/getpathp.c would
need to change which is where my concern came from.
scripts = {base/userbase}/bin
We should note that this may cause pain for a number of projects - I've
seen quite a few projects that already assume "Scripts" on Windows - eg,
virtualenv and setuptools IIRC
If you look at these projects, though, they *special case* Windows to
account for the different layout. Removing this difference will allow
these projects to remove their special-casing code.
I don't think that is true. One of the examples I offered was a .bat
file - it wouldn't be possible to remove the .bat file with your
proposal. The other example was the Windows specific launcher.
Most things that need to locate the Python executable aren't actually
Python code - once Python is running, locating the executable is as
simple as sys.executable. So by their very nature, tools needing to
locate Python will tend to be platform specific in the first place.
Can you offer any examples of 3rd party tools which could unify code in
this scheme, and particularly, where this scheme would cause them to
have less code, not more?
- and also assume the executable is where
it currently lives - one example off the top of my head is the mozilla
"jetpack" project - see:
https://github.com/mozilla/addon-sdk/blob/master/bin/activate.bat#L117
This code actually reinforces my point:
First, this code would actually still work. The section ":FoundPython"
sets the PATH to "%VIRTUAL_ENV%\bin;%PYTHONINSTALL%;%PATH%" (L80), which
would still allow python.exe to be found and run.
Second, look at that line again. Mozilla actually has edited this code
so that the jetpack uses a cross-platform "bin" convention, just as I am
proposing.
I think you misunderstand the .bat file - there is no python executable
in the bin directory. The bat file is locating your already installed
Python and attempting to use it.
Third, one element of this proposal is that there would be a key placed
in the registry that points directly to the location of the python
executable, making locating it trivial to locate programmatically on
Windows.
That sounds reasonable, but it still causes breakage, and still causes
extra code for tools needing to support earlier versions. Saying "hey,
it's easy to fix" are just words to someone frustrated trying to get
things working with a later version of Python.
Don't get me wrong - the scheme you propose is how it should have been
done in the first place, no question. My issue is the breakage this
will cause versus the benefit.
My other questions still remain: who specifically will benefit from
this, and what would be the cost to those beneficiaries of sticking with
the existing scheme? The only benefit I've seen suggested is
aesthetics, and while that is laudable, I don't think it is enough to
justify breakage.
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
