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.