[Distutils] Improving distutils' script and GUI app handling
Phillip J. Eby
pje at telecommunity.com
Thu Sep 15 18:07:54 CEST 2005
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. :)
More information about the Distutils-SIG