On Mon, Apr 20, 2009 at 19:02, P.J. Eby firstname.lastname@example.org wrote:
I thought you couldn't import setuptools in setup3.py, for all the reasons you just described?
Yes? And then you draw some sort of conclusion of this that totally escapes me.
Why do I need setup.py?
To define the core entry points, basically. These are really bootstrapped from the existing entry_points.txt (which is why it's in SVN), but they need to be regenerated at egg_info/bdist_egg/install time to match the current Python version.
OK. And why are they needed to install and test setuptools?
Apart from that, I believe setuptools only uses itself for finding its own packages (including data) and manifest building (i.e. finding files that are under SVN control).
Sure, but that's easily avoided.
So I suppose that if you dropped the use of find_packages(), you could make a setup.py that would let you run distutils commands on the code base, I just don't see how you'd get any setuptools-level commands to work properly without setuptools being imported first.
They won't work. The question is why they need to work.
None of this makes setuptools any less reliant on itself for testing and building, though, since the core entry points have to exist in order for commands to be found, options to be verified, etc.
Which still doesn't really answer the question: Why setuptools need to rely on setuptools.
Because distutils doesn't have an egg_info command
I've already mentioned that getting rid of the setuptools dependency on itself means you can't build setuptools eggs. But I've also pointed out that I don't understand why they would be needed. For all other packages it's recommended that only source distributions are done unless you have c-extensions. Why is setuptools an exception?
or SVN-based manifest building (for making sdists).
Well, we can survive without that, as far as I can see.