On Jun 13, 2008, at 4:59 AM, Armin Ronacher wrote:

...

Currently the egg installation script is called "easy_install". I would propose to rename it to something like "pyegg" or something similar. Mainly because "easy_install" is a very generic name and doesn't include anything related with python in the name which causes confusion.

Additionally if easy_install gets an uninstallation feature the name is wrong too.

-0 from me.

While your reasons are good ones, Armin, it is too late to rename easy_install.

+1 for a rename. Of course, start throwing a deprecation warning before removing the command entirely. :(

On Jun 13, 2008, at 5:48 PM, Ben Finney wrote:

zooko <zooko@zooko.com> writes:

...

While your reasons are good ones, Armin, it is too late to rename easy_install.

I don't see why. Care to give some reasons of your own?

I said it was "too late", because there are already lots of people worldwide who know the name "easy_install". It would be costly to them to change it -- they'll go looking for the new version of easy_install someday and won't find it, stuff like that. On the other hand, if there is a strong desire on the parts of developers to change it, I won't object. Regards, Zooko

--On 14. Juni 2008 08:46:02 +0200 Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote:

-On [20080614 03:18], zooko (zooko@zooko.com) wrote:

...

I said it was "too late", because there are already lots of people worldwide who know the name "easy_install". It would be costly to them to change it -- they'll go looking for the new version of easy_install someday and won't find it, stuff like that.

-100 on renaming easy_install to something else.

Also, your claim of 'lots of people worldwide' is taken out of thin air. I doubt you have evidence in favour or against.

Honestly spoken: the world has other problems than such a pointless issue. I introduced eggs, setuptools and zc.buildout within a bigger organization with several courses and hands-on-training. 'easy_install' is a well-known term right now and there is basically no need for renaming it - just for the sake of renaming it to something like 'pyegg' which is as pointless and generic as 'easy_install'. Leave things as they are - don't confuse people by renaming things - it's not worth the effort. Andreas

Jeroen Ruigrok van der Werven wrote:

-On [20080614 03:18], zooko (zooko@zooko.com) wrote:

...

I said it was "too late", because there are already lots of people worldwide who know the name "easy_install".

Nothing proper release notes and the likes cannot fix.

My objection to the name "easy_install" is that is sounds like a piece of marketing propaganda. If something based on it were to become part of the standard distribution, I would hope that a more neutral name could be found. -- Greg

On Jun 14, 2008, at 7:16 PM, Ben Finney wrote:

Greg Ewing <greg.ewing@canterbury.ac.nz> writes:

...

My objection to the name "easy_install" is that is sounds like a piece of marketing propaganda. If something based on it were to become part of the standard distribution, I would hope that a more neutral name could be found.

I share this objection.

Now that you mention it, I have heard more than one person snort derisively about the name "easy_install", and say something to the effect that it isn't a proper name. This makes me think that it causes the "anti-marketing-propaganda" reaction in some folks. Considering the opinions expressed by others in this thread, I'm changing my mind and would not object to changing the name. Regards, Zooko

Phillip J. Eby wrote:

At 02:15 AM 6/15/2008 -0700, zooko wrote:

...

Now that you mention it, I have heard more than one person snort derisively about the name "easy_install", and say something to the effect that it isn't a proper name. This makes me think that it causes the "anti-marketing-propaganda" reaction in some folks.

You seem to be under the mistaken impression that my choice of name was accidental or whimsical, rather than carefully chosen to appeal to some people at the possible expense of others.

And you can't actually avoid that tradeoff, any more than you can shove a program's complexity under the rug. All you can do is attempt to please a different group, or to please no-one. You don't get the option of pleasing everybody.

Personally I think 'easy_install' is well named and not heard of anyone who misunderstood its intent or purpose... Michael Foord

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- http://www.ironpythoninaction.com/ http://www.theotherdelia.co.uk/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/

"Phillip J. Eby" <pje@telecommunity.com> writes:

(On a side note, I find it tremendously amusing that this particular bike shed seems to be attracting the *most* attention, out of all the things that need to be fixed, improved, or replaced altogether.)

It's partly the bike-shed effect, true. On the other hand, it's been a wart for a long time, so this period of "fix things for the future" has inevitably brought this issue up. If it's going to be addressed properly, now seems like the best time. -- \ “As the most participatory form of mass speech yet developed, | `\ the Internet deserves the highest protection from governmental | _o__) intrusion.” —U.S. District Court Judge Dalzell | Ben Finney

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.)

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.

Phillip J. Eby wrote:

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.

Right. That is what I meant but worded poorly. :-)

...

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.

Still, I'd run it anyway. :-) I definitely don't have the depth of experience to know what features being exercised hit what code paths. But I do use setuptools for both building and installing on Windows XP, Mac OS X, and various Linux flavors. We heavily use eggs here at Enthought. :-)

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.)

Okay, we'll see what we can do about that here at Enthought. So far we'd been focusing on bugs / new features that we thought needed to be addressed but that effort can be redirected a bit to helping write tests. I think Tarek suggested a sprint this weekend but I'm not sure if any of our guys will be available that soon. I'll ask around. -- Dave

Tarek Ziadé wrote:

On Wed, Jun 18, 2008 at 7:14 PM, Dave Peterson <dpeterson@enthought.com <mailto:dpeterson@enthought.com>> wrote:

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.)

Okay, we'll see what we can do about that here at Enthought. So far we'd been focusing on bugs / new features that we thought needed to be addressed but that effort can be redirected a bit to helping write tests. I think Tarek suggested a sprint this weekend but I'm not sure if any of our guys will be available that soon. I'll ask around.

Ok cool,

I can spend a bit of time on sunday on this topic, writing a few scenarii. What I have been thinking of is:

- a doctest for each command setuptools provides - a doctest for easy_install - a doctest that uses setuptools/distutils to build, release, and upload a package

Anything else in mind ?

Tarek

That list looks like a great place to start :) I can spend some time this weekend working on this as well, if you want to coordinate efforts. -- Chris Galvan

-- Dave

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org <mailto:Distutils-SIG@python.org> http://mail.python.org/mailman/listinfo/distutils-sig

-- Tarek Ziadé | Association AfPy | www.afpy.org <http://www.afpy.org> Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ------------------------------------------------------------------------

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

Tarek Ziadé wrote:

On Fri, Jun 20, 2008 at 5:56 PM, Chris Galvan <cgalvan@mail.utexas.edu <mailto:cgalvan@mail.utexas.edu>> wrote:

I can spend a bit of time on sunday on this topic, writing a few scenarii. What I have been thinking of is:

- a doctest for each command setuptools provides - a doctest for easy_install - a doctest that uses setuptools/distutils to build, release, and upload a package

Anything else in mind ?

Tarek

That list looks like a great place to start :) I can spend some time this weekend working on this as well, if you want to coordinate efforts.

Sure that would be great

I can be present Sunday from 9am to 11am and after 8pm CEST time (Paris) So i guess we can meet after 8pm if you are locate in Texas ?

Tarek

Yes, I live in Texas. Anytime after 8pm CEST works great since that will be 1pm for me. Would IRC be a good discussion place to meet so that others could help out as well? -- Chris Galvan

On Jun 20, 2008, at 11:11 AM, Tarek Ziadé wrote:

Sure, let's meet at #distutils

By the way, I've noticed that people occasionally appear on irc.freenode.net channel #setuptools to ask for help with their usage of setuptools. Presumably they are just running a "list channels" tool on irc.freenode.net and noticing "#setuptools" listed therein. Perhaps they will likewise do so for the channel "#distutils". Regards, Zooko

On Jun 13, 2008, at 11:46 PM, Jeroen Ruigrok van der Werven wrote:

Also, your claim of 'lots of people worldwide' is taken out of thin air. I doubt you have evidence in favour or against.

Due to the "Shall we rename easy_install?" question, I became curious about evidence of number of users. Obviously we can't get reliable numbers of how many users there are, since people can (and do) freely copy the software and use it without sending any hint of their use to us. However, here are a few numbers that might be indicative: Google for "easy_install" has 141,000 hits. http://pypi.python.org/pypi/setuptools/0.6c8 shows the following numbers of downloads: File Type PyVer downloads ---- ---- ----- --------- setuptools-0.6c8-py2.5.egg Python Egg 2.5 66,197 setuptools-0.6c8.win32-py2.4.exe W32 installer 2.4 991 setuptools-0.6c8.win32-py2.5.exe W32 installer 2.5 5,007 setuptools-0.6c8.win32-py2.3.exe W32 installer 2.3 207 setuptools-0.6c8-1.src.rpm RPM redhat4.3 any 752 setuptools-0.6c8-py2.4.egg Python Egg 2.4 68,237 setuptools-0.6c8-py2.3.egg Python Egg 2.3 6,684 setuptools-0.6c8.tar.gz Source any 12,647 Next, I wonder about how many people got setuptools or easy_install with their operating system instead of downloading it. Unfortunately, Debian's popularity-contest seems to be broken, so I can't use that to try to get an estimate of how many Debian users use the setuptools as distributed by Debian. http://popcon.debian.org Regards, Zooko