At 01:12 PM 9/2/2007 -0700, Toshio Kuratomi wrote:
What is the real way to allow people to do quick and dirty scripting and experimentation from the interpreter shell in this environment?
Either: 1. Select the desired default version using "easy_install package==version", or 2. Have *no* default version, and always use require() (or automatically-managed dependencies declared via a setup.py script).
And once again, we are *not* creating and packaging scripts that use __require__. We are packaging multiple versions of modules with a default.
And once again, this won't work. Either you must not have a default version, or you must deal with the potential conflict in your scripts. The supported way of doing that is to generate the scripts using easy_install. If you are packaging something that doesn't use setuptools explicitly, you'll just have to patch it to declare its dependencies. You're already patching the .spec file; heck, if it would make it more palatable, perhaps we could add a way to specify the requirements via the command line. (Alternately, you could just create a requires.txt in the .egg-info directory.)
We need to have instructions for end-users who want to do quick and dirty scripting or experiment in the interpreter shell how to select the version that they wish.
easy_install package==version will change the default version, and require() will work if there is no default version. Those are the supported ways of doing this.
Once again, *we are not creating any system level python scripts that make use of a specific, non-default version*.
I'm saying that even your programs that use the default version, should explicitly specify what version they use. If you're going to support multiple versions, then declare *all* the dependencies, or at least the ones that would otherwise have conflicts.
B) For projects that have not been ported to a new version of the module. We have no control over how those upstream scripts are written -- whether they use easy_install, hand code __requires__, or munge sys.path themselves.
The correct instructions are for them to use setuptools and declare their dependencies, or live with whatever the status quo is.
This is true. But it's not going to change until all upstreams have moved to using setuptools. We provide a set of packages that work together. And we provide a means for the user to shoot themselves in the foot. But this is nothing new, they've had access to PYTHONPATH, su, rm -rf, etc in the past.
What we can do is make as much of what they expect to work work as it used to. And where it differs, we offer a standard, logical, and simple method to get the behaviour they want.
Right - and the single simplest solution for all of this is to simply use setuptools as it was designed: select a default version using easy_install, and declare dependencies for everything else. Alternatively, don't install *anything* as the default version, and declare *all* dependencies. If your goal is to have simple and consistent behavior, the second is the best choice. If you want the greatest backward-compatibility, the first is the best choice. Note that it isn't really possible for users *now* to choose a different package version at runtime, so requiring the use of easy_install to switch default versions doesn't seem like a big deal. They already have to make this choice by what RPMs they install, and it's just as global a choice -- except that this way, they can do it without breaking anything.
If you feel that __requires__ is a private method that shouldn't be used then we'd respect that. But between that and your teelling us that pkg_resources.require() isn't meant to work like that, it means that there's simply no method for making setuptools do what we need it to and we'll have to find some other method to accomplish this.
There are *two* ways to accomplish it: have a default (and use easy_install to change it when desired), or don't have a default. Either way, you are going to ultimately end up at a place where everything needs to declare its dependencies, preferably in a setup.py. Having a default version may be useful for the transition period, but the best way to encourage people to actually transition is to have some *benefit* for declaring their dependencies -- like being able to use the non-default versions. This is why I even discourage direct use of require(), as it says in the docs: """In general, it should not be necessary for you to call this method directly. It's intended more for use in quick-and-dirty scripting and interactive interpreter hacking than for production use. If you're creating an actual library or application, it's strongly recommended that you create a "setup.py" script using setuptools, and declare all your requirements there. That way, tools like EasyInstall can automatically detect what requirements your package has, and deal with them accordingly."""