[Distutils] Improving distutils' script and GUI app handling

[Phillip J. Eby]

At 10:41 AM 9/15/2005 -0500, Ian Bicking wrote:
>One issue that has come up for me is the way setuptools currently 
>generates scripts causes problems for me.  For instance, if I do 
>tag_svn_revision, then the version of my package can change in place 
>(whenever I do setup.py egg_info).  The script has a version hardcoded in 
>it, and so it fails.

Run "develop" instead of "egg_info", and your active scripts will be 
upgraded.  (The "develop" command also runs "egg_info" as a subcommand.)


>   Also, if we support multiple versions of packages, each with a script 
> tied to that version, then there needs to be an easier way to control the 
> script names, e.g., --script-suffix=0.4 or something.

That would indeed be handy.


>The other issue is which Python version is used to load the script; it's 
>not uncommon to want to switch versions.  It would be nice if there was 
>something -- an option, perhaps, or an environmental variable -- which 
>could override the Python version.  E.g. script 
>--python-version=python2.4, or PYTHON_VERSION=python2.4 script (I don't 
>think the later isn't reasonable to do in Windows, though)

I don't think this can be made to work in any meaningful fashion, since 
eggs are specific to a particular Python version (because of bytecode 
format differences), and may contain different modules or entry points or 
dependencies for different Python versions.  For example, if somebody 
packages a new module for use with older Pythons, users of that package 
will likely have their setup() include a dependency for the 
separately-packaged module if running on the older Python.  Another 
example: setuptools doesn't publish an entry point for the 'build_py' 
command when running on Python 2.4, but it does on 2.3 because the 2.3 
build_py command doesn't support installing package data.


>>* Should launchers hardcode their sys.path?  This would prevent breakage 
>>caused by installing new and incompatible versions of their dependencies, 
>>but require an explicit upgrade action to update them, and make the 
>>installation process more complex.
>
>I'm wary of hardcoding paths.  I don't think we should completely embrace 
>encapsulation -- it might be better for long-term stability (maybe), but 
>it makes it harder to fix a system that is broken (even when "brkoen" just 
>means one missing requirement).

Well, with a sufficiently complex launcher, you could have it try to fix 
the problem (e.g. by running EasyInstall to find the missing bits).  But I 
guess we can just evolve that way over time.  :)