[Distutils] testing with eggs
Phillip J. Eby
pje at telecommunity.com
Sat Aug 20 06:37:38 CEST 2005
At 10:04 PM 8/19/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>I'm kind of confused. Maybe what you want is to create dummy
>>Distribution objects and add them to a WorkingSet, then use the
>>WorkingSet's APIs in your tests (such as iter_entry_points, require(),
>>etc.). It's not entirely clear to me what it is that you're testing, so
>>I'm not sure.
>I'm testing loading WSGI apps out of eggs using entry points. So there
>will be real code in those test packages, though just stubby code. I'm
>not testing setuptools per se, so dummy Distributions probably won't be of
Note that entry points don't have to point into the egg; they just get
imported. Thus, you might as well point the entry points back into your
test code, with no need to create a separate package. All you really need
are Distribution objects with dummy "entry_points.txt" metadata resources.
>>>At first I tried adding fake_packages to sys.path; didn't work at all.
>>Because the subdirectories' names don't end in .egg; if they did and you
>>just used EGG-INFO instead of .egg-info, it would work.
>OK, I'll try that. I was surprised, though, that FakeApp.egg-link didn't
>work until I added the directory as addsitedir. Though I was flailing
>about to get it working, so I don't know what exactly combination of
>things I ended up using.
>I also realize it would be nice to refresh the egg_info before running the
>tests, but I'm not sure how well that will work if it happens in the same
>process as the tests themselves. Or how I run a setup() command from Python.
That's why I think you'll have an easier time just creating dummy
Distributions with entry point metadata that links back into your test
code; then you don't have to even have real packages inside the eggs, nor
do you have to manipulate sys.path any. Since you're not testing
setuptools, that should work fine for your purposes, if I understand them
correctly. All you really want to test is that your code makes the right
calls on a working set and invokes your stub entry points.
Just make your code take a WorkingSet as a parameter, and default to
pkg_resources.working_set (the global WorkingSet). Your test code will
pass in its own WorkingSet instances, which will not affect sys.path or the
global pkg_resources state. But your code will be able to call require(),
resolve(), iter_entry_points(), and all the other standard APIs, because
these are WorkingSet methods anyway. The global working_set's methods are
exported by pkg_resources as module-level APIs, but code like yours should
operate on a WorkingSet instance and just default to the global one.
More information about the Distutils-SIG