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

[warner]

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.

[warner]

FYI, I just added an OS-X buildslave.

[zooko]

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.

[zooko]

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]

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.

[zooko]

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