[Distutils] Disabling --single-version-externally-managed

[Phillip J. Eby]

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 
resolve conflicts).

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.