At 08:00 PM 11/30/2009 +0200, cool-RR wrote:
On Mon, Nov 30, 2009 at 7:57 PM, P.J. Eby
<<mailto:p...@telecommunity.com>p...@telecommunity.com> wrote:
At 02:09 PM 11/30/2009 +0000, Ram Rachum wrote:
I've asked before about bundling Distribute. But now I ask, is it possible to
pull out the `pkg_resources` module from the Distribute folder and bundle only
that with my project?
If your project is a standalone application with a completely
isolated sys.path, then yes, you can bundle it. If your project is
a library or shares sys.path directories with other libraries or
applications, then no, *do not bundle it*.
(This is true even for the original pkg_resources, but it's doubly
true for Distribute's pkg_resources, as installing it may break a
setuptools-based installation's ability to upgrade setuptools.)
What I was thinking is to put it in its own package, and then import
it like `from my_package import pkg_resources`.
Would that still be problematic?
Not if your modules are the only ones using any pkg_resources APIs
within a given program. But consider what happens if both your
package and another package are calling 'require()' -- just to give a
really simple example. You will have two working_set objects that
don't agree with each other, or with sys.path. (Similar issues may
also apply for other pkg_resources data structures and APIs.)
Bundling pkg_resources is really not a good idea for anything but a
100% standalone application or similarly controlled environment,
where you know that nothing else will be doing that kind of
thing. (Bundling it alongside your setup.py to use during
installation -- but not actually installing it -- would also be
relatively safe.)
If all you're worried about is that a user's version of setuptools
might have some sort of bug in pkg_resources, you needn't be. It's
the single most stable part of the setuptools code base, both in the
senses of "infrequently changing" and "not a lot of bugs". Even if
someone's using a version of pkg_resources that's say, 2 or 3 years
old, you're not likely to see any bugs more severe than a spurious
warning message that something might be being imported from more than
one place.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
