[Distutils] [issue24] Rename easy_install

[Phillip J. Eby]

At 06:27 PM 6/16/2008 -0500, Dave Peterson wrote:
>Phillip J. Eby wrote:
>>At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
>>>Any discussion of that sort seems to get hopelessly
>>>bogged down, so bikeshedding is all that's left for
>>>people to do.
>>
>>What about testing patches?  Writing test code?  Writing more docs?
>>There's *plenty* of less controversial work to go around.  The only 
>>reason most of the outstanding patches I'm aware of haven't been 
>>applied yet is because they haven't been tested.  (Or more 
>>precisely, because setuptools hasn't been thoroughly tested with 
>>the patches applied.)
>
>
>I can help test some of the patches

Don't test patches - test setuptools with the patches.  :)  More 
precisely, make sure you test things beyond what the patch is 
supposed to do, to make sure that other things aren't affected.  This 
is particularly important for patches to easy_install, which is 
ridiculously complicated
due to all the obscure edge cases it has to be able to handle.


>  I've seen people posting to the tracker, but I can't commit to 
> svn.   Beyond running the setuptools test suite

The test suite is pretty useless for most of these kinds of 
patches.  It essentially only exercises various internals of 
pkg_resources and a few other things that are almost never 
touched.  I'm talking testing as in "actually install some packages 
in a few different kinds of install targets, using a few different 
options".  I don't have a rigorous process for that, as I tend to 
pick things on the basis of the code paths to be exercised.  But that 
might not be an option for casual testers.

If I had it all to do over -- and I didn't simply run screaming from 
attempting the task in the first place -- I would write a full 
functional test suite, including chrooting tests if necessary.  In 
the long run, it would have saved enormous amounts of manual test 
time, and we could have had more people involved in development a 
long time ago.

That, by the way, is why "writing test code" is on the list above.


>and verifying that things seems to work for me and my environment, 
>is there anything else that will help get some of the patches into svn?
>
>BTW, most of those things you mention all effectively boil down to 
>writing patches in one way or another. :-)  How do we make sure that 
>after they get some review they get checked in when it seems so few 
>people have check-in privileges?  Phillip, you already mentioned 
>that you're short on time and no one else has responded to a plea 
>for finding out who has check-in privileges.

Jim Fulton has previously been "blessed" by me to apply 
non-controversial patches to setuptools after giving me a 
heads-up.  (But note that he's probably busier than I am, and 
unlikely to have bandwidth for stuff that doesn't affect zc.buildout 
or Zope in some way.)

If you want to expand the available development pool for setuptools, 
I would strongly suggest focusing development efforts on creating a 
regression test suite emphasizing end-to-end functional testing of 
the current functionality.  Such tests would ideally be factored for 
narrative clarity and compact expressiveness, rather like Jim 
Fulton's doctests for easy_install's .exe wrappers, and the doctests 
for zc.buildout.  (Because if they're too complicated for me to read, 
they'll take too long for me to review.)

If people *really* want to solve the development bottleneck, this is 
the way to go, because it will reduce my role to deciding whether 
something should go in, and seeing if it passes the tests on a 
platform or two.  That's something I think I could manage to do, even 
with my current work load.