Open woutervh opened 9 years ago
I don't quite understand the situation. Any chance for me to reproduce the issue?
Steps to reproduce:
[buildout]
parts = check-manifest
[check-manifest]
recipe = zc.recipe.egg
And here's the error:
building an sdist
['/tmp/cleanenv/bin/python', 'setup.py', 'sdist', '-d', '/tmp/check-manifest-nLHfR_-sdist'] failed (status 1):
Traceback (most recent call last):
File "setup.py", line 3, in <module>
from setuptools import setup
ImportError: No module named setuptools
Actually the interesting zest.releaser commit is https://github.com/zestsoftware/zest.releaser/commit/48ab8433.
So the thing is: check-manifest
itself doesn't depend on setuptools. Therefore when you use it with zc.buildout, the bin/check-manifest
script won't have setuptools added to sys.path. Therefore setting PYTHONPATH for the child process won't help.
It would likely help your use case, where check-manifest is invoked from zest.releaser, since zest.releaser depend on setuptools. I'd appreciate it if you could test this patch:
diff --git a/check_manifest.py b/check_manifest.py
index 75c251e..43773aa 100755
--- a/check_manifest.py
+++ b/check_manifest.py
@@ -127,9 +127,15 @@ def run(command, encoding=None):
"""
if not encoding:
encoding = locale.getpreferredencoding()
+ if command and command[0] == sys.executable:
+ # Workaround for zc.buildout, bootstrapped from a Python that lacks
+ # setuptools (see https://github.com/mgedmin/check-manifest/issues/35)
+ env = {'PYTHONPATH': os.pathsep.join(sys.path)}
+ else:
+ env = None
try:
pipe = subprocess.Popen(command, stdout=subprocess.PIPE,
- stderr=subprocess.STDOUT)
+ stderr=subprocess.STDOUT, env=env)
except OSError as e:
raise Failure("could not run %s: %s" % (command, e))
output = pipe.communicate()[0].decode(encoding)
In the end, I'm not sure what to do. The process of making source distributions is python setup.py sdist
. If your setup.py
needs setuptools
, you should run it with a python
that has setuptools. check-manifest
lets you specify a python
command to use with the -p
command-line flag. In other words, I don't think there's need to add a workaround to the main check-manifest
script. But the zest.releaser plugin, OTOH, has no way to supply a different Python command, and if this workaround fixes your use case, I'll commit it.
@WouterVH any chance you can test this patch? I'd like to make a check-manifest release soon.
I confirm this patch fixes the problem. Tested with python 2.7.10 and check_manifest 0.25
Thank you!
Hm. Should I also add a dependency on setuptools in my setup.py?
I had to revert the zc.buildout support hack because it breaks other things -- see #56.
my use-case, I have a "tools"-buildout that installs zest.releaser, fabric, and check-manifest,... this buildout is bootstrapped from a clean python that deliberatetly has no setuptools installed, (so it can never conflict with a buildout-provided setuptools).
the check_manifest takes sys.executable as default python see https://github.com/mgedmin/check-manifest/blob/master/check_manifest.py#L572 while this is correct, the executable looses its sys.path,
A similar issue was fixed in zest.releaser, see https://github.com/zestsoftware/zest.releaser/issues/57 https://github.com/zestsoftware/zest.releaser/pull/58/files
as far as I see, the same solution ban be re-used.