[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 zooko):

 Well, I still feel like it is better to maintain the packaging tests and
 the Tahoe-LAFS code separately. I don't foresee it being a problem that
 there is "divergence" between the packaging tests and the Tahoe-LAFS code.
 Those two things probably oughtn't be changed in tight synchronization
 with each other anyway!

 I've had problems in the past with packaging code accidentally importing
 the wrong version of a package, and it was very confusing, so I feel
 nervous about the packaging tests coming with a copy of the code-under-
 test in a sibling directory. I think it could cause trouble.

 > 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.

 I don't think this is easy! I find this stuff very confusing. You can't
 rely on setting {{{PYTHONPATH}}}, by the time you can edit {{{sys.path}}}
 it is sometimes too late, you can't rely on editing {{{sys.modules}}}
 (although I occasionally have to do that). Having your Python code crawl
 around in your file system and look for magic files in sibling
 directories, like we do in {{{bin/tahoe}}} is icky and non-standard, even
 though it has worked so far {{{bin/tahoe}}}'s purposes.

 In short, if I want some code (the packaging tests) to have control over
 what specific copy of some other code (the code-under-test) it starts
 with, then my preferred way of achieving that is:

 1. The test code starts with no extant copies of any version of the other
 code present on its filesystem.

 2. The test code fetches a specifically chosen version, by tarball-
 download of a specific URL, or by git fetch of a specific branch, tag, or
 commit-hash.

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