> 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. >
Okay. But I don't use `require()`, the only thing I need from `pkg_resources` is the ability to extract resources from folders. So will there be any problem if I bundle it for that? Ram.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig