Anthony Baxter wrote: > And now let's look at some of the stuff that setuptools gives us: > > - We have a CPAN-type system I think it is unfair (to Richard Jones) to attribute this to setuptools. We already have a CPAN-type system: the Cheeseshop. What setuptools adds is roughly the CPAN shell (ie. CPAN.pm or however it is implemented). Actually, I think it is ez_setup that provides (something like) the CPAN shell. It is my understanding that setuptools itself has nothing to do with a CPAN-like system, just as Makemakefile.pl has nothing to do with CPAN. > - Multiple installs of different versions of the same package, > including per-user installs. I never had the need, but I trust others do. > - The "develop" mode > > This makes life that bit less painful all-round. This could be added to distutils with no problems, right? > - The plugin/extension support > > Extending distutils currently is a total pain in the arse. If that's a desirable feature to have, it *should* be added to distutils; IOW, it should be available if you do "from distutils import setup", not just when you do "from setuptools import setup". > I'm a little suprised by the amount of fear and loathing this has > generated. To me, there are such obvious benefits that I don't see > why people are so vehemently against setuptools. I haven't seen any > arguments that have convinced me that this isn't the right thing to > do. Yes, there's still work to be done - but hell, we've only > released the first alpha so far. I'm not looking at it from a end-user's point of view. I trust that setuptools provides features that end-users want, and in a convenient way. My fear is in the maintainer's side: how many new bug reports will this add? How much code do I have to digest to even make the slightest change? That is says from itself that it is version 0.7a1dev-r45536 doesn't help to reduce that fear. > I'm also suprised by how much some people seem to think that the > current state of distutils functionality is acceptable or desirable. > It's not - it's a mess. I would like to require that this is solved by contributing to distutils, instead of replacing it. I know this is an unrealistic request to make - in particular because there is only a single developer world-wide which actively develops "something like that". Requiring Phillip to rewrite distutils instead is certainly unfair - but I'm still unhappy with the path events take. > Finally, I'd like to point out that I think some of the hostility > towards Phillip's work has been excessive. I'd like to make clear that my hostility is only towards his work; never towards Phillip Eby himself. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4