Some negative press for easy_install
Hi, Joe Gregorio has a fairly negative experience with easy_install here: http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusivel... I think his points boil roughly down to these: 1. (not directly related to his first comment, but I think this might be a source of problems) easy_install isn't always called easy_install. In my case I've wound up with easy_install.py on some systems at some point in the past. Would a possible solution be to allow "python -m easy_install"? Then again I think it's pretty consistent these days. 2. No --prefix option. I think this is a case of RTFM, since it's not normally as simple as specifying a prefix. Maybe a help message which explains why --prefix isn't supported might be useful? 3. In the error message he gets it shows bog standard distutils help, so he tries --help-commands and gets an error. I think this is a definite source of frustration. 4. He tries the --install-dir option which installs the package but of course this leads to a multi-install so he can't do a plain import foo. It might be good to link to http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-loca... for an explanation here. 5. At this point he gives up and copies the source from svn. I think in all the above there is an element of RTFM but he does have a legitimate point when it comes to the command line help, based off that alone you aren't likely to figure out the best way to use easy_install if you are doing a non-system python install. I think a link to http://peak.telecommunity.com/DevCenter/EasyInstall in the help would work wonders. cheers, Michael
Whoops, I just noticed previous messages on this, ignore me. Michael On 09/02/06, Michael Twomey <micktwomey@gmail.com> wrote:
Hi,
Joe Gregorio has a fairly negative experience with easy_install here: http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusivel...
I think his points boil roughly down to these:
1. (not directly related to his first comment, but I think this might be a source of problems) easy_install isn't always called easy_install. In my case I've wound up with easy_install.py on some systems at some point in the past. Would a possible solution be to allow "python -m easy_install"? Then again I think it's pretty consistent these days.
2. No --prefix option. I think this is a case of RTFM, since it's not normally as simple as specifying a prefix. Maybe a help message which explains why --prefix isn't supported might be useful?
3. In the error message he gets it shows bog standard distutils help, so he tries --help-commands and gets an error. I think this is a definite source of frustration.
4. He tries the --install-dir option which installs the package but of course this leads to a multi-install so he can't do a plain import foo. It might be good to link to http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-loca... for an explanation here.
5. At this point he gives up and copies the source from svn.
I think in all the above there is an element of RTFM but he does have a legitimate point when it comes to the command line help, based off that alone you aren't likely to figure out the best way to use easy_install if you are doing a non-system python install. I think a link to http://peak.telecommunity.com/DevCenter/EasyInstall in the help would work wonders.
cheers, Michael
On 2/9/06, Michael Twomey <micktwomey@gmail.com> wrote:
Hi,
Joe Gregorio has a fairly negative experience with easy_install here: http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusivel...
I think his points boil roughly down to these: [...] 5. At this point he gives up and copies the source from svn.
This is the one that struck me as the biggest issue. Joe is right that setuptools is still in alpha - so authors offering setuptools-based installs should be fully aware that they risk breakage, frustration, and similar from their users. That's to be expected. If you don't like the pain of alpha software, then avoid it. If routes *needed* setuptools functionality, then fine - but explain this prominently somewhere: "This package uses setuptools, which is currently in alpha status - there may be issues installing or using the software. If you hit any problems, please report them to the distils-sg, and thank you for helping to test setuptools". But clearly routes does not need setuptolols functionality (or the Routes tests aren't complete - as Joe said that all the tests run). So why not provide a non-setuptools build, for users who don't want to fight with the bleeding edge? Just my 2p worth... Paul.
On Feb 9, 2006, at 3:55 AM, Paul Moore wrote:
If routes *needed* setuptools functionality, then fine - but explain this prominently somewhere: "This package uses setuptools, which is currently in alpha status - there may be issues installing or using the software. If you hit any problems, please report them to the distils-sg, and thank you for helping to test setuptools". But clearly routes does not need setuptolols functionality (or the Routes tests aren't complete - as Joe said that all the tests run). So why not provide a non-setuptools build, for users who don't want to fight with the bleeding edge?
It's mainly because Routes is relied on by quite a few other setuptools-enabled packages, so being able to easy install it was necessary. I didn't have a non-setuptools build mainly because I couldn't see how to setup a setup.py file in such a way that I could make both versions at once. I'm assuming I'd need two setup.py's and to swap them in the build depending on if it was a setuptools build or not. Not a lot of fun, but I can see the utility of it for those not wishing to grapple with setuptools. Does this mean there should perhaps be some criteria or a recommendation to developers using setuptools on when they should still supply a non-setuptools build of their project? - Ben
On 2/9/06, Ben Bangert <ben@groovie.org> wrote:
It's mainly because Routes is relied on by quite a few other setuptools-enabled packages, so being able to easy install it was necessary. I didn't have a non-setuptools build mainly because I couldn't see how to setup a setup.py file in such a way that I could make both versions at once. I'm assuming I'd need two setup.py's and to swap them in the build depending on if it was a setuptools build or not.
Could you do something like this: try: from setuptools import setup except ImportError: from distutils.core import setup On your system, you'd then be able to build eggs at will. Other people who download an sdist but don't have setuptools will just get normal sdist-like behavior. Kevin
Ben Bangert wrote:
I didn't have a non-setuptools build mainly because I couldn't see how to setup a setup.py file in such a way that I could make both versions at once. I'm assuming I'd need two setup.py's and to swap them in the build depending on if it was a setuptools build or not. [...]
See http://initd.org/tracker/pysqlite/changeset/227 I just changed pyqlite's build process so that you can build without setuptools again. setup.py is the traditional distutils script. extended_setup.py is the one that imports everything from setup.py and adds additional setuptools features. HTH, -- Gerhard
At 08:02 AM 2/9/2006 -0800, Ben Bangert wrote:
On Feb 9, 2006, at 3:55 AM, Paul Moore wrote:
If routes *needed* setuptools functionality, then fine - but explain this prominently somewhere: "This package uses setuptools, which is currently in alpha status - there may be issues installing or using the software. If you hit any problems, please report them to the distils-sg, and thank you for helping to test setuptools". But clearly routes does not need setuptolols functionality (or the Routes tests aren't complete - as Joe said that all the tests run). So why not provide a non-setuptools build, for users who don't want to fight with the bleeding edge?
It's mainly because Routes is relied on by quite a few other setuptools-enabled packages, so being able to easy install it was necessary.
FYI, easy_install works with distutils packages just fine, as long as they don't get too fancy in their customization.
I didn't have a non-setuptools build mainly because I couldn't see how to setup a setup.py file in such a way that I could make both versions at once. I'm assuming I'd need two setup.py's and to swap them in the build depending on if it was a setuptools build or not.
Not a lot of fun, but I can see the utility of it for those not wishing to grapple with setuptools. Does this mean there should perhaps be some criteria or a recommendation to developers using setuptools on when they should still supply a non-setuptools build of their project?
I think the criterion is simply this: if you don't want to have to inform your users about the things listed in the "What Your Users Should Know" section of the manual, then you should make setuptools optional for the time being. When that section of the manual is effectively built in to setuptools, then you won't need to supply that extra information. However, in most cases the notification to users can be as simple as Paul Moore's suggested wording and a link to the Custom Installation docs.
At 07:59 AM 2/9/2006 +0000, Michael Twomey wrote:
Hi,
Joe Gregorio has a fairly negative experience with easy_install here: http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusivel...
I think his points boil roughly down to these:
1. (not directly related to his first comment, but I think this might be a source of problems) easy_install isn't always called easy_install. In my case I've wound up with easy_install.py on some systems at some point in the past. Would a possible solution be to allow "python -m easy_install"? Then again I think it's pretty consistent these days.
It has been consistent throughout 0.6, and I think it was even at some point in 0.5. There is still an "easy_install" module whose sole purpose is to tell you that "python -m easy_install" doesn't work any more, and that will go away in 0.7.
2. No --prefix option. I think this is a case of RTFM, since it's not normally as simple as specifying a prefix. Maybe a help message which explains why --prefix isn't supported might be useful?
After thinking this over, I've decided that by 0.6b1 (yes, I'm going beta) easy_install should be able to detect that it's self-installing and should verify that your system is adequately prepared for installation, and if not, display helpful hints about what's wrong and links to the docs. That should fix the RTFM issue here, and bypass the concern about whether package authors are informing people about TFM. :) In the interim, I think I should probably create a user-targeted quickstart page, along the lines of "If you've never used EasyInstall, here's what you should know", and ask package authors to link to it.
3. In the error message he gets it shows bog standard distutils help, so he tries --help-commands and gets an error. I think this is a definite source of frustration.
Yeah, I've been putting off fixing that because customizing that message is basically impossible without copying a crapload of code. But it's definitely a requirement for 0.6b1.
4. He tries the --install-dir option which installs the package but of course this leads to a multi-install so he can't do a plain import foo. It might be good to link to http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-loca... for an explanation here.
Yeah, and a shorter URL would help, too. :) But mainly, checking the configuration on an initial install to make sure the system's configured to begin with would be helpful. Maybe eventually an interactive configuration mode that edits your config files for you would be even better.
5. At this point he gives up and copies the source from svn.
I think in all the above there is an element of RTFM but he does have a legitimate point when it comes to the command line help, based off that alone you aren't likely to figure out the best way to use easy_install if you are doing a non-system python install. I think a link to http://peak.telecommunity.com/DevCenter/EasyInstall in the help would work wonders.
participants (6)
-
Ben Bangert -
Gerhard Häring -
Kevin Dangoor -
Michael Twomey -
Paul Moore -
Phillip J. Eby