And it breaks one of my scripts when run inside buildout, as the script by necessity does a "python setup.py --name" to get at the name as defined in a setup.py in some package. The output of --name now includes those warnings....
Can I have your ouputs guys ? This warning is supposed not to pop any warning anymore when importing module/package names that are part of Distribute.
Also, check if this is not related to an environment where you are using Setuptools, and where its was not properly patched because of the zc.buildout bootstrapping that hardcodes setuptools dependency.
I tried using the bootstrap you provided, but that seemed to hose my global python's setuptools installation. The bootstrap cannot write to the system directory, so you have to sudo, which lead to other problems. But I could not reliably debug that one as I had to focus on other bugs at that time. If I can reproduce, I'll open a separate bug for that.
I've had the problem on two different machines: something automatically tried to exchange setuptools for distribute but failed halfway. I had to copy the old setuptools egg back in to be able to easy_install distribute... easy_install complained about something like "python -c xxxxxx not valid".
But I need to do more tests, I'll try to finish this this week.
If you try to apply manually this patch in the zc.buildout that gets in your eggs/ and if you run the script located in http://bitbucket.org/tarek/buildout-distribute/ it should work. Let me know if you try please, that could help providing a new zc.buildout release that works with Distribute, with a minimal impact.
I'm trying out the bootstrap + buildout patch right now.
But the problem remains with other buildouts: you don't control all buildouts you have. So buildout ought to work without warnings when you only exchange your global setuptools for distribute. Otherwise people get scared.
Stated dependency: if I use the new bootstrap plus buildout but nothing actually depends on distribute (but something *does* depend on setuptools), distribute is not in the sys.path. And I get the warnings again.
And something else is wrong, too: once distribute has changed the setuptools egg in my .buildout/eggs directory, every other buildout (which is unmodified or which has to distribute dependency) gets the warnings. (Probably as it falls back
So something in the distribute replacement stuff isn't complete. If the distribute egg is not on your sys.path, the patched setuptools is ignored or not found and it -as far as I can see- falls back to the global setuptools. And if you haven't replaced that one with distribute, you again get the warnings.
Which would mean "fix the warnings" or "wait with using distribute in buildouts until everyone has switched". And I'd like to switch earlier...
In the following, by "unpatched setuptools" I mean a setuptools egg that hasn't been replaced/mocked/whatever by distribute.
I found out the one situation in which I get setuptools warnings when using buildout.
I have an unpatched global setuptools and a patched setuptools in buildout's egg cache, but I don't use distribute myself. In that case, a setuptools import falls back on the global setuptools, but it does find some distribute here and there and issues warnings.
When it goes right:
a) If I have an unpatched global setuptools and a patched setuptools in the buildout egg cache and I also require distribute somewhere in my buildout, everything works just fine. The global setuptools is never seen and distribute correctly replaces setuptools at runtime.
b) If I have a patched global setuptools and a patched setuptools in the buildout egg cache, everything goes OK even if I don't depend on distribute in my buildout.
c) If I don't use a buildout egg cache and if my egg there has never been patched before (by experimenting) and left in place.
For it to go wrong, you need
- an unpatched global setuptools
- a buildout egg cache that has a setuptools patched by some other buildout (or by yourself in case you've later removed a distribute dependency)
- a buildout that effectively uses the patched setuptools egg, but doesn't depend on distribute.
Stated dependency: if I use the new bootstrap plus buildout but nothing
actually depends on distribute (but something *does* depend on setuptools),
distribute is not in the sys.path. And I get the warnings again.
No because the custom boostrap installs Distribute in your buildout.
I really hope it still makes sense :-)
yes that makes sense but unfortunately we can't handle these cases because you will always find combinations where a real setuptools might be located in the path. So I don't think we can get totally rid of those warnings.