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. :) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
