[tahoe-lafs-trac-stream] [tahoe-lafs] #2049: Decide where "packaging tests" should live.

[tahoe-lafs]

#2049: Decide where "packaging tests" should live.
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  warner
  nejucomo               |     Status:  new
         Type:  task     |  Milestone:  soon (release n/a)
     Priority:  normal   |    Version:  1.10.0
    Component:  dev-     |   Keywords:  packaging dev-infrastructure
  infrastructure         |  buildbot pypi
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 I'm -0. I'll create that repo if you want, but first I'd like to push back
 on the notion that these tests ought to live outside of the main source
 tree.

 > Zooko points out that if the tests live in the main tahoe-lafs
 repository, then when they are invoked they may incorrectly import the
 local unpackaged code, or make other dependency mistakes.

 I think it's easy to avoid that. Our `bin/tahoe` looks in its parent
 directory for the marker file that indicates it should include `../src`
 and `../support`, etc. But if we unpack the sdist into a subdirectory, and
 run the new `bin/tahoe`, it won't look in the original tree for anything.

 (One counter-example would be if something in the build process wants to
 know if it's in a git checkout, for which `git` walks all the way to the
 filesystem root looking for a `.git` directory. I don't think that's a big
 deal.)

 More repositories means more places for contributors to look, more
 divergence between code and tests. Also it raises the buildbot question of
 which repo's changes should trigger the tests being run (presumably you'd
 want to trigger on changes in either source-repo or tests-repo, and that's
 not trivial with buildbot).

 My weak suggestion would be to put all of these "packaging tests" into a
 subdirectory of the main tree, and have the buildbot (or whatever) check
 out trunk, then run one of them. The packaging tests should not feel
 obligated to use the rest of the source code for anything, but if the test
 happens to need a trunk checkout, one is nearby. I could be talked out of
 this, though.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2049#comment:11>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage