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