[tahoe-dev] problems with the build/install/test process

[Brian Warner]

> > Brian wants to just be able to run 'python setup.py trial' and have  
> > it do the right thing on any platform, which I agree with.
> 
> Isn't the actually *right* thing to do to fix twisted #2234 (Select  
> default reactor based on platform and available libraries)?

For future versions of Twisted, sure. But we seem to be trying to be
compatible with some number of old platforms (dapper, etc), and sometimes
that compatibility is of the form where we're obligated to use the
platform-provided version of Twisted. So some of this job is workarounds for
bugs that we can't get rid of by instructing the user to upgrade.

Zooko and I have talked about a "debian/ubuntu compatibility matrix", in
which the rows are releases (dapper, hardy, sid, etc), and there are two
columns. The first column is "Tahoe can be built/tested/run from source on
this platform". The second column is "a Tahoe .deb (and all necessary support
debs) can be installed/tested/run on this platform". To put a "YES" in the
second column, we aren't allowed to upgrade any of the platform-provided
libraries. We may have debian platforms which will support Tahoe from source,
but not from a .deb (i.e. in which the platform's setuptools is too old).

If we don't have a workaround for twisted#2234, we might want to split this
second column into two: "tahoe can be installed/run on this platform", and
"tahoe can be installed/tested/run on this platform". On the platforms that
offer a version of twisted in which #2234 is fixed (which is none of them
right now, even sid doesn't yet have Twisted-8.2.0, and I'm not 100% sure
that Twisted-8.2.0 fixes #2234), we can install and run a .deb, but not test
it. (Also note that many platforms have a version of pyopenssl that doesn't
trigger the bug, so we can test on those even without a fix for #2234).

> >> Next: hardy
> ...
> >> Hm, this points to a deeper problem: the buildbot's attempt to run  
> >> "trial allmydata" to test the current source code from its newly  
> >> installed location might accidentally run the unit tests of a  
> >> different version of allmydata installed in the system.
> > I agree, this one may be a little bit harder to track down :/  The  
> > traceback given by buildbot is not very helpful.

"import" should import whatever comes first in the PYTHONPATH, right? So it
should be a simple (heh) matter of insuring that the source tree or the newly
installed location appears earlier in PYTHONPATH? 'trial' adds the current
directory to sys.path before importing the code-under-test, so it's designed
to either be run from a source tree (and test the code in that source tree),
or from anywhere other than a source tree (and test the code that's installed
on your system: whatever get used when you do 'import').

I must say, seeing how badly setuptools futzes around with sys.path, I can't
say I feel confident that the ordering of PYTHONPATH matters anymore. I miss
this loss of confidence and control.

> Ideally I would want the buildbot to assert that it is really importing and
> testing the source code that it is supposed to be. Could we add to the
> buildbot script to import the allmydata package and inspect its __file__
> attribute and fail the buildstep if it isn't the path we were expecting?

Perhaps the "tahoe version" command should sprout a --verbose flag, which
could emit the import location of each module it uses ('import allmydata;
print allmydata.__version__, str(allmydata)').

I think that the _trial_tmp/test.log (which is captured by the buildbot as
'test.log' during a trial run) includes the import location of the allmydata
module, in case that helps.

cheers,
 -Brian