[Distutils] Proposal for Distribute 0.7

ssteinerX@gmail.com ssteinerx at gmail.com
Fri Oct 16 16:46:49 CEST 2009

On Oct 16, 2009, at 4:24 AM, Tarek Ziadé wrote:

> On Fri, Oct 16, 2009 at 3:39 AM, ssteinerX at gmail.com
> <ssteinerx at gmail.com> wrote:
>> Some of the files (e.g. setuptools/archive_util.py) are only  
>> different by a
>> bit of whitespace.
> archive_util, in the mid term (2.7/3.2) will dissapear, in favor of
> changes in Distutils side.

Ok, it was just a datapoint, not a suggestion that it be retained.

>> 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.
> We had a "setuptools-compatible" branch for a while when PJE said he
> might use our work to release setuptools, but that didn't happened  
> and we moved on.
> [please no flame here,it's just a fact : it didn't happen. period]
> At  this point, the code base is backward compatible, but is slightly
> changing yes (we are working in bug fixes so..)

Ok, after reviewing the code, I can see that maintaining "common code"  
would not actually be a good idea because it's not worth retaining.

>> 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?"
> Yes absolutely. Then if you keep them coming and you will be able the
> have a contributor access.

Thanks.  At the moment, I, frankly, wouldn't touch that code with a 10  
foot pole.  I had never actually sat down to do anything resembling a  
"code review" on the setuptools code and, after doing so, I really  
think it should just be scrapped as quickly as possible.  Dragging any  
of it along, for whatever reason, is just going to slow progress.  The  
test coverage is pretty much non-existent and, without that, trying to  
figure out the intent of this code is pointlessly difficult.  It'd  
just be easier to write the tests, write the code, and move on.

> As, for the quality of the code, the current quality is very low in
> many ways, so, for obvious bug patches, we trust anyone that is
> already running a project succesfully, and we are counting on the fact
> that many eyes are now watching the changesets being done.
> Remember that 0.6.x is bugfix only.


> The only hard part in setuptools is understanding what the code is
> doing because it's hard to read, overdesigned and overcomplex and with
> giant monolithic modules.

I don't know that I'd call what I saw "designed."   Complex, yes, but  
design implies a plan and known direction, communicated by design  
documents with tests that prove the code is working as expected.

This is not designed by any objective standard I'd use.

Maybe PJE is some sort of savant who can keep the myriad details of a  
piece of code like this in his head but "design" is not that.

>> 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.
>> 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 ! we will fix it. The code base is not well covered in the
> tests, so this problem was not tackled. Notice that the latest  
> released, if run under Python
> 3, will convert in the fly the code, using 2to3, so make sure the  
> tests are run after 2to3 (that's
> what is supposed to happen)

Yes, I'm sure 2to3 can fix it, but the less work it has to do, the  
fewer chances for mistakes in the automatic conversion.  Not that I'd  
expect this to break something but having the 2to3 log less cluttered  
with simple things like this that can be easily done by hand cuts down  
on the amount of stuff that has to be reviewed in case of a problem.

> If you find anything else, please come in #distutils (freenode)

Will do...


More information about the Distutils-SIG mailing list