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.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
