[Distutils] Disabling --single-version-externally-managed
Phillip J. Eby
pje at telecommunity.com
Sun Sep 2 21:06:33 CEST 2007
At 11:37 PM 9/1/2007 -0700, Toshio Kuratomi wrote:
>I realize that taken in the vacuum of that single easy_install run,
>require() works. But the instructions are neglecting to tell the user
>that things are more complex than that. That depending on how the other
>versions of the module are installed, pkg_resources may not work at all.
You're taking this out of context. When you run "easy_install -m",
the normal result is that *there is no default package*. So
require() is both necessary and sufficient in that case.
> Since __require__ works for this instance and for a mixture of -m and
>- -s isn't it best to give users instructions that they can use everywhere?
The problem is that you are adding a new situation to "everywhere",
that previously didn't exist -- mixing single-version and
multi-version at the system packaging level.
Either have a default version and deal with conflicts, or no default
version and be explicit. __requires__ is a workaround to avoid
conflicts in specific cases. It is intended only as a workaround,
and really it's only for tools like easy_install and zc.buildout that
generate scripts from a project description.
I do not intend to support it for any other usage. If you, as a
packager, wish to package scripts that use __requires__, I don't see
a problem with that. It is emphatically *not* intended for general use.
There are already tools in place to do what you want; you're just
trying to get away with not using them.
To put it another way, if you want to support multiple versions with
a default, then you need to support the *end-user being able to
choose* what version is the default. If the user does an
easy_install of some specific version, then *that* version needs to
become the default. And the only way to support that, is for you to
generate your scripts with easy_install or zc.buildout, or to make
your own tool that generates scripts using __requires__. If you
don't, then your system-level Python scripts will be hosed if the
user changes the default version of a package they use.
Now, it could be argued that you have packages that don't declare
their dependencies currently (i.e., they don't use setuptools), and
would also be hosed by a change in the default version. But if
that's true, then you're not fully supporting multiple versions.
So, my point here is that this issue is inherent to the nature of
multiple versions. Either you have a default, or you don't. If you
don't, you can't have conflicts but have to be explicit. If you do
have a default, then you need to *let the user change it*, and make
everything you supply be explicit (so that it will automatically
I don't plan to support __requires__ for end-user scripts, but I'm
happy to co-ordinate with system-level packagers and the authors of
packaging tools to make sure you don't get messed up when it
(eventually) goes away and is replaced by something better.
More information about the Distutils-SIG