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. :)