[Distutils] Setuptools for Python 2.5

[Phillip J. Eby]

At 11:26 PM 9/12/2006 +0100, Paul Moore wrote:
>On 9/12/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>Actually, that's not the reason.  Python 2.5 requires setuptools 0.7a1,
>>which is only available from SVN.
>
>Ah. In that case, the error is misleading but at least the solution is
>straightforward :-) But I built and installed 0.6c2 as a bdist_wininst
>and things seemed to be sort-of working. What actually goes wrong?
>Something clearly does, but it's far from obvious...

To be honest, I've completely forgotten at this point.  You could skim the 
"svn log" looking for things related to Python 2.5 if it really 
matters.  :)  I just remember that I had to make changes.  Some were minor 
things, like Python 2.5 distutils including its own "upload" command, and 
others were more substantial, possibly related to other distutils changes 
or to language changes.


>>setup.py install.  Be sure to use the 0.7a1 version from the trunk.
>
>OK, cool. Does the fact that I can use setup.py install also mean I
>can just build a bdist_wininst and install that? That was what the
>single-version-externally-managed format was about, yes? If so, do I
>miss out on any of the multi-version features by doing things this
>way?

Nope.  There are only two things that the SVEM format can't do (besides 
being uninstalled without a packaging system):

1. It can't include __init__.py for "namespace packages" (packages like 
peak.* and zope.* that are split across separate distributions).  You can 
have namespace packages, mind you, it's just that you can't include 
anything in the __init__.py for the package, because it's not installed 
when a SVEM installation is done.

2. Project-level data files, i.e., resources in the "root" of an 
egg.  There's no way for you to access these resources if a project is 
installed SVEM, because there's no per-project directory for that stuff to 
go in.

These are both extremely rare things to have in a project.


>Fair enough. Presumably, as automatic building from source should have
>worked, this doesn't imply a higher dependency on distributors
>providing binary eggs than the old approach did.

Correct.