-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
setup.py issue w/stevedore==0.12 #147
Comments
Here I show that the problem does not exist with stevedore==0.11 .
|
I'm not sure if this is the only problem, but it might be related to the fact that you're still using distribute. Now that setuptools and distribute have merged again, it's better to just rely on having setuptools installed. I would remove distribute_setup.py from your package and change setup.py to not import it. (see #148) You might also want to have a look at pbr (https://github.com/openstack-dev/pbr/) for handling things like requirements.txt, automatic version and package detection, and a bunch of other simplifications to packaging. |
See #150 instead. |
cc/@dhellmann - pulling private thread back into this issue. I have been testing against the system's /usr/lib/python2.7/site-packages. No tox or virtualenv involved. I am now more convinced that this problem has nothing to do with the environment. Starting with a fresh build of python2.7.5, installed the latest setuptools and pip following the guidelines on pip-installer.org. Next created a "useless" library with a distribute-less setup.py a'la #150 and with the same requirements.txt as aminator. Running the useless setup.py results in error and trace below. The stack trace differs but the error is the same as in issue #147.
Here setup.py is run in the pdb. dist is type instance?
|
That's definitely odd. We have seen that error many times with the new setuptools, and it has always been due to upgrading setuptools as a dependency of another project. As a test, I ran pip against aminator's trunk ("pip install .") from before I submitted the pull request (commit 96efa7d), and it worked (even though distribute does end up being installed). Running "python setup.py install" fails, as you reported. This is pretty much the behavior we've seen in the past with the setuptools upgrade issue. hubert:aminator (git:master:96efa7d "2.0.174")$ mktmpenv Downloading/unpacking boto>=2.7 (from aminator==2.0.174-dev)
Downloading/unpacking bunch (from aminator==2.0.174-dev) Downloading/unpacking decorator (from aminator==2.0.174-dev)
Downloading/unpacking distribute (from aminator==2.0.174-dev) Downloading/unpacking envoy (from aminator==2.0.174-dev) Downloading/unpacking logutils (from aminator==2.0.174-dev) Downloading/unpacking pyyaml (from aminator==2.0.174-dev) Downloading/unpacking requests (from aminator==2.0.174-dev) Downloading/unpacking stevedore (from aminator==2.0.174-dev)
Downloading/unpacking simplejson (from aminator==2.0.174-dev) Requirement already satisfied (use --upgrade to upgrade): setuptools>=0.7 in /Users/dhellmann/Envs/tmp-b0f6521dd9663fda/lib/python2.7/site-packages (from distribute->aminator==2.0.174-dev)
Running setup.py install for bunch Running setup.py install for decorator
Running setup.py install for envoy Running setup.py install for logutils Running setup.py install for pyyaml
Running setup.py install for requests Running setup.py install for stevedore Running setup.py install for aminator
Running setup.py install for distribute Successfully installed boto bunch decorator envoy logutils pyyaml requests stevedore simplejson aminator distribute |
cc/@dhellmann
cc/@jd
During the installation of requirements phase of setup.py, the module installed following the installation of stevedore fails with the stacktrace below and setup.py terminates. This only seems to be a problem when setup.py installs stevedore. That is, a subsequent run of setup.py succeeds because stevedore is already installed.
This problem can be avoided by pinning the stevedore==0.11.
The text was updated successfully, but these errors were encountered: