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.