Opened at 2010-11-15T02:04:08Z
Last modified at 2016-03-26T21:30:45Z
#1260 closed defect
there should be a way to force compiling C extensions from source — at Initial Version
Reported by: | davidsarah | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | 1.11.0 |
Component: | packaging | Version: | 1.8.0 |
Keywords: | install setuptools docs test | Cc: | |
Launchpad Bug: |
Description
On tahoe-dev, Zooko O'Whielacronx wrote:
One of the goals for this release is to let people on more platforms more easily set up Tahoe-LAFS. (Problems with the setup process are probably the number one complaint mentioned on the mailing list and issue tracker right now.)
Tahoe-LAFS itself is pure Python and doesn't need to be compiled at all, but some of its dependencies do, so a big part of the "ease of setup" goal is to provide binary packages of those dependencies.
Scott Dial replied:
I actually found this release less easy to install. On my linux machines, neither the setup.py or using easy_install yielded working dependencies for my system. Eventually I tracked it down to the pycryptopp binary egg:
[snip problem due to a libstdc++ ABI mismatch]
After solving the mystery, I was forced to resort to introspection:
$ python -c "import sys; \ sys.path.insert(0, 'src/allmydata'); \ from _auto_deps import install_requires; \ print '\n'.join(install_requires)" \ | xargs -I{} pip install "{}" # This dependency gets missed for some reason: $ pip install pyOpenSSL
To get all of the dependencies to be built by my system (easy_install will use the binary eggs, and there is no way to force it to ignore them), pip was the only tool I could find that would do it without me being involved.
This release took infinitely longer to install than 1.7, where I just ran "python setup.py build" and "python setup.py install" and was done.
We need to support an option to force compiling the C/C++ code in dependencies from source, for users who either encounter problems with the binary eggs, or just prefer to do it that way.