Closed
Bug 632362
Opened 14 years ago
Closed 14 years ago
Ship test environments without the requirement for users to compile Mercurial
Categories
(Mozilla QA Graveyard :: Mozmill Crowd Extension, defect)
Mozilla QA Graveyard
Mozmill Crowd Extension
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: whimboo, Assigned: whimboo)
References
Details
Attachments
(2 files, 1 obsolete file)
988 bytes,
patch
|
aaronmt
:
review+
|
Details | Diff | Splinter Review |
1.43 KB,
patch
|
aaronmt
:
review+
|
Details | Diff | Splinter Review |
In the last days I got a couple of reports from users that something is broken with the test environment on OS X. Also during the FOSDEM I got the same report from Chris Hofmann, who run into that problem on 10.6. The failure is the following:
$ ./setup.sh
Overwriting ./lib/python2.6/orig-prefix.txt with new content
New python executable in ./bin/python
Error [Errno 2] No such file or directory while executing command
install_name_tool -change /Library/Frameworks/Python.fra...ython
@executable_path/../.Python ./bin/python
Could not call install_name_tool -- you must have Apple's development
tools installed
[..]
./setup.sh: line 7: ./bin/activate: No such file or directory
Searching for mercurial
Reading http://pypi.python.org/simple/mercurial/
Reading http://mercurial.selenic.com/
Reading http://www.selenic.com/mercurial
Best match: mercurial 1.7.5
Downloading http://mercurial.selenic.com/release/mercurial-1.7.5.tar.gz
Processing mercurial-1.7.5.tar.gz
Running mercurial-1.7.5/setup.py -q bdist_egg --dist-dir
/var/folders/cw/cwpFd4A8FPCwh2RAKsq29++++TI/-Tmp-/easy_install-UjDato/mercurial-1.7.5/egg-dist-tmp-LBgtrz
error: Setup script exited with Python headers are required to build
Mercurial
Users of the Mozmill Crowd extension should never have to install the X-Tools on their system. We have discussed that for a bit during FOSDEM and came to the conclusion that the best option is to ship the environment with a pre-compiled mercurial module on Linux and OS X.
Assignee | ||
Comment 1•14 years ago
|
||
Ian, given the problems we have discovered by shipping a pre-configured virtualenv environment to our users which require mercurial compiled on their systems, I would be curious to know how safe it is to use the relocatable option of the virtualenv script.
http://virtualenv.openplans.org/#making-environments-relocatable
When we pre-compile and install mercurial in a locally created virtualenv, will that then work on users systems?
Assignee | ||
Comment 2•14 years ago
|
||
Brian, today I have talked with Alexandre about the way how the Jetpack SDK handles the virtual environment for Python. He told that you are responsible for that part now. That's correct? If yes, can you help us with your experience? I think the problem we have at the moment has been described above. Would that be possible to distribute such an environment across different machines? Seems like you are not using PyPI at all for dependent packages.
Comment 3•14 years ago
|
||
If they need the Python headers, it's a sign that something needs to be compiled (it's possible it's an optional speed-up that needn't be installed, but there's no standard way of suppressing that). If it needs to be compiled then it's not really portable across systems, so a relocatable environment doesn't have any real benefit (also moving around binaries on Macs can be hard, as they tend to hardcode things in their binaries unless you use Mac-specific techniques that I only partially understand). If you do want to ship a binary for Mac systems then it probably makes sense to use a Mac-specific installer.
Another option is to try not to install Mercurial unless it is necessary, fail gracefully when it doesn't work, and direct them to existing installers for that specific package.
Assignee | ||
Comment 4•14 years ago
|
||
Ok, so good new here. Today I did some research and have found that it is possible to install Mercurial without the dependency of the c-code compilation. In such a case everything will be a bit slower but that doesn't matter at all for us.
Steps:
1. Download the latest version from pypi or the project page
2. Run './setup.py --pure install'
That way there is no need to have the dev environments installed on OS X and Windows, and we even don't have the dependency to python-dev modules on Linux.
I will play around with it today and lets see that we can release a new environment later this week.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Summary: Ship test environments with pre-installed tools (at least Mercurial) → Ship test environments without the requirement for users to compile Mercurial
Assignee | ||
Comment 5•14 years ago
|
||
Ian, do you know of a way to directly install such a package via the --pure option via pip? Or is there no way to forward those options to the setup script?
Comment 6•14 years ago
|
||
You can do:
pip install Mercurial --install-option="--pure install"
But it'll pass that option to every setup.py script, so if you install any dependencies they probably won't support that option and so it'll break. So install any dependencies first, then install Mercurial alone using that option.
Assignee | ||
Comment 7•14 years ago
|
||
(In reply to comment #6)
> pip install Mercurial --install-option="--pure install"
Sadly that line doesn't work. Pip still wants to compile the c-code. Could that be broken in the mercurial package?
Comment 8•14 years ago
|
||
If you add -v (or maybe -vv) then pip will show you exactly what command it is running -- it's a little more verbose than just "python setup.py --pure install" but it is something similar to that.
Oh... maybe the problem is that it should be --install-option="--pure" as the "install" part is the command that is run anyway. Somehow I was reading that as though "install" was an argument to --pure.
Assignee | ||
Comment 9•14 years ago
|
||
I talked with Ian on IRC and as we found out the right command has to be:
pip install mercurial --global-option="--pure"
Strangely this command does not work on OS X. I will have to figure out what's the difference there.
Assignee | ||
Comment 10•14 years ago
|
||
Ok, so the issue on OS X was related to a problem with my site-packages. Now it's working fine. We don't want to change the setup code for Window right now, so this patch only includes the patches for Mac and Linux.
Beside the issue on that bug we also have a problem installing virtualenv on a machine which does not have the Apple development tools installed. I will file a follow-up bug for that specific case, so we can try to ship a complete test environment with all tools already installed. Similar to what the Add-ons SDK (https://github.com/mozilla/addon-sdk) is doing.
Attachment #519543 -
Flags: review?(aaron.train)
Assignee | ||
Comment 11•14 years ago
|
||
(In reply to comment #10)
> Beside the issue on that bug we also have a problem installing virtualenv on a
> machine which does not have the Apple development tools installed. I will file
> a follow-up bug for that specific case, so we can try to ship a complete test
> environment with all tools already installed. Similar to what the Add-ons SDK
> (https://github.com/mozilla/addon-sdk) is doing.
I have filed bug 642027 for that remaining issue. Also lets get in this fix for the next Mozmill Crowd release 0.1.2.
No longer blocks: 623204
Updated•14 years ago
|
Attachment #519543 -
Flags: review?(aaron.train) → review+
Assignee | ||
Comment 12•14 years ago
|
||
Landed as:
https://github.com/whimboo/mozmill-crowd/commit/3efd679d74cf3703e0d53cc6dc72484c09fe2d6d
That means we have no dependency on Linux anymore which is great. The remaining work will happen on bug 642027.
I have uploaded the new environments so those are already available for new users.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•14 years ago
|
||
Tested on a fresh install of Ubuntu and it still fails. Looks like pip can't really handle that and we have to call the setup.py script on our own.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 14•14 years ago
|
||
More a hack at the moment and I hope we can get rid of it hopefully soon.
Attachment #521377 -
Flags: review?(aaron.train)
Assignee | ||
Comment 15•14 years ago
|
||
For both Linux and OS X, even the latter will not work because of the above mentioned limitations.
Attachment #521377 -
Attachment is obsolete: true
Attachment #521378 -
Flags: review?(aaron.train)
Attachment #521377 -
Flags: review?(aaron.train)
Comment 16•14 years ago
|
||
Comment on attachment 521378 [details] [diff] [review]
Followup v2
Tested on Ubuntu and OSX, works fine.
Attachment #521378 -
Flags: review?(aaron.train) → review+
Assignee | ||
Comment 17•14 years ago
|
||
Follow-up landed as:
https://github.com/whimboo/mozmill-crowd/commit/c77a65d6524129ad62f0c36abed63e4be65b4a34
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•