[Distutils] Proposal for Distribute 0.7

[ssteinerX@gmail.com]

Warning: 3 part message.

It's all related so I decided to bundle it rather than starting  
several new threads on the already over-burdened distutils list.

On Oct 15, 2009, at 5:06 PM, Tarek Ziadé wrote:

> Now, ssteinerX, what do you mean exactly by shared foundation ?

Well, at the moment, setuptools 6.10rc and Distribute 0.6.6 share only  
one identical directory; tests. (tests in the root directory which  
only contains shlib_test which I'm not even sure is used by anyone)

Many other files are only different by a few lines, some additions to  
Distribute are just for Python 3 compatibility.

Some of the changes are only in the way message text is distributed  
over a couple of lines (the kind of clean-up people naturally do as  
they're assimilating a product they didn't write), some extra  
comments, sometimes the wording (Couldn't vs. Could not) of an error  
message.

Some of the files (e.g. setuptools/archive_util.py) are only different  
by a bit of whitespace.

In taking a closer look, the two products are still very close to each  
other but it would take a careful person a solid few days or a week to  
merge them back together into a single code-base, if that would even  
be desirable.

I had thought going forward would be to take some of the utility type  
functionality that is unlikely to change (archive_util.py for example)  
and move them to a shared utility library.

This is probably unrealistic given the dynamics of the current  
situation, but it was a nice idea ;-).

Thanks,

S

P.S.

While I was in there, I did a little actual work.  Not much, but now I  
feel like I've made a contribution, however small... ;-).   Does this  
make me a "contributor?"

This is from the archive pulled down by:

	# wget http://pypi.python.org/packages/source/d/distribute/distribute-0.6.6.tar.gz

While I was pawing around, I noticed that, in distribute-0.6.6/ 
setuptools/command/alias.py, line 12, the <> operator is used.

Since that's not allowed in Python 3.x, the test suite must not cover  
this 'cause Python 3 would barf.

So...I whipped out my command line and:

	find . -name "*.py" -exec grep "<>" {} \; -print

I get:

(~/src/distribute-0.6.6/setuptools)# find . -name "*.py" -exec grep  
"<>" {} \; -print
     if arg.split()<>[arg]:
         if self.remove and len(self.args)<>1:
./command/alias.py
             if safe is None or bool(safe)<>flag:
./command/bdist_egg.py
         if self.verbose<>self.distribution.verbose:
                 if k<>'target_version':
             if len(parts)<>2 or not name.endswith('.pth'):
./command/easy_install.py
             str(version)<>"unknown" and version >=  
self.requested_version
./depends.py
                     if p<>package and not p.startswith(pfx)
                     if p<>package and not p.startswith(pfx)
                     if p.name<>package and not p.name.startswith(pfx)
./dist.py
             if cs.hexdigest()<>info[4:]:
./package_index.py

Those aren't going to fly in Python 3 and can be safely removed for  
2.x as well.  A patch would be silly, just go fix it ;-).

Thanks,

S

P.S.S.

Part of the problem we'd have with merging the two products to form a  
single codebase is that there are some differences between the ways  
the tickets have been closed in the two products.

Distribute's fixes are committed against the bugs in its tracker so  
it's pretty easy to see what change fixed what.  Not so much in  
setuptools where many things are in one big mega-commit.

>> The latest commit you've made in setuptools package is still  
>> cryptic to us because
>> it fixes many things at once.
>
> Sorry about that, but it was pretty much the only way to get it done  
> in a weekend, without the overheads of separate commit messages, doc  
> changes, and backporting killing me.  Those overheads were the main  
> reason I wasn't making changes more often; I dreaded the amount of  
> work involved.
>
> Also, as it happened, I was able to fix multiple problems with  
> single changes this way.

I don't mean to take another pot-shot a PJE, but the facts is the  
facts and this shows clearly why the product with the open development  
process should be the one supported by the community.

> Also, I've made it pretty plain for a long time that if Ian Bicking  
> or Jim Fulton were ever willing to take it over, I'd hand it *all*  
> over -- 0.7 as well as 0.6 -- and happily retire from the  
> distribution tools business.

I'd love to see this be the last release of setuptools so if you're  
the aforementioned "Ian" or "Jim", could you please, please, very  
temporarily, accept the burden of "setuptools maintainer" so it can  
die an elegant, compatible, controlled, peaceful death, being merged  
into and supplanted by Distribute after long and good service to the  
Python world?

We really need a good, modern, open, constantly evolving packaging  
system to keep Python competitive.

Thanks,

S