[tahoe-lafs-trac-stream] [tahoe-lafs] #1651: remove exec() from the codebase

[tahoe-lafs]

#1651: remove exec() from the codebase
------------------------+------------------------
     Reporter:  warner  |      Owner:  somebody
         Type:  defect  |     Status:  new
     Priority:  major   |  Milestone:  eventually
    Component:  code    |    Version:  1.9.0
   Resolution:          |   Keywords:
Launchpad Bug:          |
------------------------+------------------------

Comment (by davidsarah):

 Replying to [ticket:1651 warner]:
 > We've had a number of "what version of the code are we running anyways?"
 problems, provoking tremendous heroics in the setuptools-based dependency-
 version-management code, that could go away entirely if we got rid of the
 use of {{{exec()}}} in the codebase (reducing the use of {{{fork()}}}
 would be good too, but not as critical).

 It's not as simple as that; if we don't set PYTHONPATH then we need to
 munge sys.path instead. As far as I can see this doesn't by itself do
 anything to solve any of the related bugs.

 It ''does'' make it possible to then munge sys.path differently, and more
 correctly, to how setuptools does it. But don't underestimate the amount
 of work needed to do that right.

 > To keep {{{tahoe start}}} from killing off the trial process during unit
 tests, we can do a {{{fork()}}} inside {{{tahoe start}}} before calling
 twistd. We should investigate how well this works on windows (I think we
 might skip that test on windows anyways).

 No, almost all of the subprocess tests work on Windows (and there are a
 lot of them).

 I don't see the advantage of not creating subprocesses in tests. It
 doesn't simplify anything as far as I can see, and if it means we are
 doing something different on Unix than on Windows, it just makes things
 more complicated. (It might improve the speed of the relevant tests
 slightly, but I'm not sure that would be a significant proportion of the
 total time.)

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