[Distutils] testing with eggs

[Phillip J. Eby]

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 
>much use.

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.