'make test' won't run trial on Mac OS-X #177

Closed
opened 2007-10-13 23:26:00 +00:00 by warner · 5 comments
warner commented 2007-10-13 23:26:00 +00:00
Owner

I built tahoe on my new Mac with the following steps:

  • install the "universal" 2.5 mac installer from python.org
    • (this goes into /Library/Frameworks/Python.framework/Versions/2.5/ and below)
  • download twisted, unpack, run 'python setup.py install' from zope-interface and .
  • download OpenSSL from http://pyopenssl.sourceforge.net, 'python setup.py install'
  • 'make build-deps'
  • 'make'

Pretty easy! But then I did 'make test', and it didn't even get started:

...
PYTHONPATH="/Users/warner/stuff/tahoe/trunk/src:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/foolscap-0.1.7-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/Nevow-0.9.18-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/setuptools-0.6c7-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/simplejson-1.7.3-py2.5-macosx-10.3-fat.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/tahoe_deps-1-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/zfec-1.1-py2.5-macosx-10.3-fat.egg:" \
 python -u "no trial.py in /Library/Frameworks/Python.framework/Versions/Current/bin /bin /sbin /usr/bin /usr/sbin" --rterrors   allmydata
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python: can't open file 'no trial.py in /Library/Frameworks/Python.framework/Versions/Current/bin /bin /sbin /usr/bin /usr/sbin': [Errno 2] No such file or directory
make: *** [test] Error 2

It looks like the trial.py-finding windows workaround blew up, because the
'which' command on OS-X emits an error message to stdout when it can't find
something, rather than emitting nothing:

$ which trial.py
no trial.py in /Library/Frameworks/Python.framework/Versions/Current/bin /bin /sbin /usr/bin /usr/sbin

This confuses the Make rule that runs 'which':

TRIALPATH=$(shell which trial.py 2>/dev/null)
ifeq ($(TRIALPATH),)
TRIALPATH=$(shell which trial 2>/dev/null)
endif
ifeq ($(TRIALPATH),)
TRIALPATH=$(shell $(PYTHON) -c "import os, sys; print repr(os.path.join(sys.prefix, "Scripts", "trial.py"))")
endif
ifeq ($(TRIALPATH),)
TRIALPATH=$(shell $(PYTHON) -c "import os, sys; print repr(os.path.join(sys.prefix, "Scripts", "trial"))")
endif
}}}

It looks like /usr/bin/which on OS-X is of a different lineage (BSD) than the
'which' that's on my linux box (debian).

As a local workaround, I can just comment out these TRIALPATH lines. For the
longer run, I'd like to find something else. Also, I'd really prefer to run
trial on sensibly-installed systems as just 'trial', rather than knowing that
it's really a python script and running it as 'python /path/to/trial'. It
just seems cleaner that way.

I built tahoe on my new Mac with the following steps: * install the "universal" 2.5 mac installer from python.org * (this goes into /Library/Frameworks/Python.framework/Versions/2.5/ and below) * download twisted, unpack, run 'python setup.py install' from zope-interface and . * download OpenSSL from <http://pyopenssl.sourceforge.net>, 'python setup.py install' * 'make build-deps' * 'make' Pretty easy! But then I did 'make test', and it didn't even get started: ``` ... PYTHONPATH="/Users/warner/stuff/tahoe/trunk/src:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/foolscap-0.1.7-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/Nevow-0.9.18-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/setuptools-0.6c7-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/simplejson-1.7.3-py2.5-macosx-10.3-fat.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/tahoe_deps-1-py2.5.egg:/Users/warner/stuff/tahoe/trunk/support/lib/python2.5/site-packages/zfec-1.1-py2.5-macosx-10.3-fat.egg:" \ python -u "no trial.py in /Library/Frameworks/Python.framework/Versions/Current/bin /bin /sbin /usr/bin /usr/sbin" --rterrors allmydata /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python: can't open file 'no trial.py in /Library/Frameworks/Python.framework/Versions/Current/bin /bin /sbin /usr/bin /usr/sbin': [Errno 2] No such file or directory make: *** [test] Error 2 ``` It looks like the trial.py-finding windows workaround blew up, because the 'which' command on OS-X emits an error message to stdout when it can't find something, rather than emitting nothing: ``` $ which trial.py no trial.py in /Library/Frameworks/Python.framework/Versions/Current/bin /bin /sbin /usr/bin /usr/sbin ``` This confuses the Make rule that runs 'which': TRIALPATH=$(shell which trial.py 2>/dev/null) ifeq ($(TRIALPATH),) TRIALPATH=$(shell which trial 2>/dev/null) endif ifeq ($(TRIALPATH),) TRIALPATH=$(shell $(PYTHON) -c "import os, sys; print repr(os.path.join(sys.prefix, \"Scripts\", \"trial.py\"))") endif ifeq ($(TRIALPATH),) TRIALPATH=$(shell $(PYTHON) -c "import os, sys; print repr(os.path.join(sys.prefix, \"Scripts\", \"trial\"))") endif }}} It looks like /usr/bin/which on OS-X is of a different lineage (BSD) than the 'which' that's on my linux box (debian). As a local workaround, I can just comment out these TRIALPATH lines. For the longer run, I'd like to find something else. Also, I'd really prefer to run trial on sensibly-installed systems as just 'trial', rather than knowing that it's really a python script and running it as 'python /path/to/trial'. It just seems cleaner that way.
tahoe-lafs added the
code
major
defect
0.6.0
labels 2007-10-13 23:26:00 +00:00
tahoe-lafs added this to the undecided milestone 2007-10-13 23:26:00 +00:00
warner commented 2007-10-14 00:23:22 +00:00
Author
Owner

FYI, I just added an OS-X buildslave.

FYI, I just added an OS-X buildslave.
zooko commented 2007-10-14 02:48:57 +00:00
Author
Owner

For the record, the reason I don't invoke just "trial" at this point is that if I install twisted from source it doesn't produce a "trial" executable on Windows. (The binary GUI "installer" does, but I really prefer not to rely on such a thing.)

twisted #1286 would allow twisted to use the setuptools executable-builder feature which would make an executable "trial" on Windows when building from source.

For the record, the reason I don't invoke just "trial" at this point is that if I install twisted from source it doesn't produce a "trial" executable on Windows. (The binary GUI "installer" does, but I really prefer not to rely on such a thing.) [twisted #1286](http://twistedmatrix.com/trac/ticket/1286) would allow twisted to use the setuptools executable-builder feature which would make an executable "trial" on Windows when building from source.
zooko commented 2007-10-14 02:53:41 +00:00
Author
Owner

P.S. In the meantime, I will see why my current "find trial.py" hack works on my two Mac systems and not yours and see if we can tweak the hack to keep it working well enough until a setuptoolified Twisted comes out. How does that sound?

Also we could just predicate the "find trial" hack on detecting the platform, although I really like to avoid platform-switches. It's just a personal preference, but I tend to prefer:

weird_hack_that_works_everywhere()

over

if platform in good_set:
clean_approach()
elif platform in wacky_set:
wacky_approach()
elif platform in weird_set:
weird_have_that_works_everywhere()

P.S. In the meantime, I will see why my current "find trial.py" hack works on my two Mac systems and not yours and see if we can tweak the hack to keep it working well enough until a setuptoolified Twisted comes out. How does that sound? Also we could just predicate the "find trial" hack on detecting the platform, although I really like to avoid platform-switches. It's just a personal preference, but I tend to prefer: weird_hack_that_works_everywhere() over if platform in good_set: clean_approach() elif platform in wacky_set: wacky_approach() elif platform in weird_set: weird_have_that_works_everywhere()
zooko commented 2007-10-15 13:47:34 +00:00
Author
Owner

I'm putting this in Milestone v0.6.1 because I want the buildbot to be All Green for the release and because I'm sure I can fix this one way or another soon.

I'm putting this in Milestone v0.6.1 because I want the buildbot to be All Green for the release and because I'm sure I can fix this one way or another soon.
tahoe-lafs modified the milestone from undecided to 0.6.1 2007-10-15 13:47:34 +00:00
zooko commented 2007-10-15 18:08:10 +00:00
Author
Owner

fixed by changeset:bf3f629a683fd4cb (the OS-X buildslave is disconnected, but I reproduced the bug and tested the fix on my Macbook Pro ("ootles").

fixed by changeset:bf3f629a683fd4cb (the OS-X buildslave is disconnected, but I reproduced the bug and tested the fix on my Macbook Pro ("ootles").
tahoe-lafs added the
fixed
label 2007-10-15 18:08:10 +00:00
zooko closed this issue 2007-10-15 18:08:10 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#177
No description provided.