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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4