[Python-ideas] Changing the default install location, script versioning (Packages and PEP 370)

Antoine Pitrou solipsis at pitrou.net
Tue Jul 21 11:01:01 CEST 2009


Jesse Noller <jnoller at ...> writes:
> 
> I don't know if easy_install does or doesn't - I simply used it as an
> example. What I don't parse is that python -m <module> is somehow a
> replacement for ./script - the logic within a script can do a lot more
> than just firing off the __main__ of a module. Are we saying that
> "scripts are considered harmful" and recommend people only support -m
> for this?

I don't think so. I interpret Paul's suggestion as "if you need a
multi-versioned script, then you can use the 'python -m' feature instead". But
you can continue running scripts in the other cases.

> There's over 7000 packages, applications and libraries in the
> cheeseshop right now. A fair number of them would run face first into
> the non-versioned binary problem.

Well, that's your contention actually :)
My contention is that a /very small number of them/ would run into the
non-versioned binary problem, because only applications which are themselves
used for deployment (easy_install, pip, etc.) may need to be invoked with an
explicit version of the interpreter.

Once again, I don't understand why you care which version of the interpreter
random application X works with (for example Mercurial, as in Brett's message).
/Apart/ from easy_install, pip and friends, that is.

> I guess distutils (in a future
> version) should just deprecate the scripts/entry points options
> entirely?

Certainly not. Perhaps it could grow an option to generate versioned scripts
easily, however. By the way, easy_install already comes versioned on the systems
I work on (you can run `easy_install-2.6` explicitly, for example).

> I really don't think this is an edge case, or should be unsupported.
> Sure, the same problem exists outside of the .local directory - you
> run into this installing things into the default system-level
> site-packages and /usr/bin /usr/local/bin directories, but there's no
> real reason we can't make this work better in the context of .local

The real reason, IMO and as I've said, is that it makes life harder for people
who don't care.





More information about the Python-ideas mailing list