The whole point of naming distutils2 “packaging” in the standard library is to avoid name conflicts in case someone wants to import a distutils2 version from site-packages that’s newer than the packaging version in the standard library.  However the main command-line entry point, the pysetup script, has a conflicting name: both packaging and distutils2 use it.

I don’t have an elegant solution to that; suggestions welcome.

Good catch,

One solution would be to have the pysetup script name suffixed by the 
version of python is comes with. For instance, for python 3.3 it would 
be "pysetup3.3" (that's how it is atm).

This means that "pysetup" would point to "pysetup3.3" after a fresh 
python install, but distutils2 could change this and propose a 
different version of pysetup.

The 3.3 version would still be available but under "pysetup3.3".

I’m afraid that won’t work: depending on how python3 is installed, it may install both pysetup3.3 and pysetup3, so distutils2-python3 can’t use any of these names.

Note that on Debian and probably other systems, two packages really cannot use the same file path without using some machinery; just overwriting something is not permitted.

(On a related topic, I’m not sure distutils2 should ever install pysetup or pysetup3 without version number: contrary to e.g. a mail client where I don’t care about the version used, this is a version-specific program that should have a version number in its name.)

The problem really is that when we talk about “the 3.3 version of pysetup” we may talk about the one that comes with packaging or with d2.