You didn't answer my question about whether I can just yank out `pkg_resources.py` and use it.
What would be the use case for this ? I don't think it's the best
practice to bundle other projects modules like that in most cases.
Up to now I've been requiring my users to install Distribute, but one of them expressed reluctance to install it, partly because of the shadowing of setuptools.
The only extra features Distribute provides are:
- python 3 support - the upload_doc command
The rest is the same APIs, minus some bug fixes we did, and the code that prevents concurrency problems with an installed setuptools.
So if you just depend on pkg_resources, it means that your program can also work with Setuptools.
So I would suggest to tell this user to install the tool he wants, and just warn him that he might bump into bugs in Setuptools that were fixed in Distribute.
Well, that sort of sucks. And this is my motivation for bundling the `pkg_resources` from Distribute. The last thing I want is having my software fail for my users because of setuptools while I have Distribute installed locally and can't see the bug on my computer.
IOW, choosing between Distribute or Setuptools should be up to your users, *unless* you use python 3 support in your setup.py, that is only present in Distribute.
And as far as I can see, Distribute as a drop-in replacement works well, besides some glitches we had to fix in zc.buildout and virtualenv because those were "married" to setuptools.
Semi-related: If I can help in convincing this user, let me know
I tried a bit, but I don't want to bother him more than I currently am. Ram.