[tor-bugs] #6810 [Flashproxy]: Reduce code duplication across client programs

[Tor Bug Tracker & Wiki]

#6810: Reduce code duplication across client programs
-----------------------------+--------------------------
     Reporter:  dcf          |      Owner:  dcf
         Type:  enhancement  |     Status:  needs_review
     Priority:  minor        |  Milestone:
    Component:  Flashproxy   |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by dcf):

 Replying to [comment:13 infinity0]:
 > Replying to [comment:12 infinity0]:
 > > Replying to [comment:11 dcf]:
 > > > I'd like to retain the ability to run the client programs from
 within a source checkout, if possible. Could we put the `flashproxy`
 package directory next to the client programs, the way it ends up with
 `make dist`? Or is that weird from a Python packaging point of view?
 > >
 > > Yes, this now makes more sense that we are merging fac.py into it too.
 But note that in the pending proposed setup, it is still possible to run
 from checkout with e.g. PYTHONPATH=common ./flashproxy-client. It's not
 unusual for source repos to forgo the ability to run-from-checkout if the
 install process is smooth.
 >
 > I just took another look and I don't think this is a good idea now. If
 we have flashproxy/ in the top-level, we also must have setup.py and
 MANIFEST.in in the top-level, plus anything else we might want to add
 later. This would cause some confusion on which files belonged to -client,
 vs -common.

 It seems to me that someone having a source checkout won't be confused by
 -client versus -common because the question will never enter their mind. I
 don't think we have to divide the source code based on how the Debian
 packages are divided.

 We have a `setup.py` in the top level already, only for py2exe purposes. I
 would be fine with adding library installation code to it, if that's
 convenient. I suppose there is some danger that people will see the
 `setup.py` and automatically assume they should run `python setup.py
 install`. (But that danger exists already.) Any other files we decide to
 add to support the distutils installation of the common libraries, we
 should strive to keep as few as possible. I'm thinking maybe one or two
 files over the next few years, not five or ten.

 What I'm trying to say is that having `MANIFEST.in` and `setup.py` in the
 root is fine with me, if you decide that is better than alternatives.

 > Are you OK with running things like PYTHONPATH=common ./flashproxy-
 client? To make the process easier I can create a script `init-dev-env`
 that exports this, so you can just do `. ./init-dev-env` then run
 `./flashproxy-client` as normal.

 Having to set PYTHONPATH is annoying but probably tolerable. I would
 rather not have an `init-dev-env` script; let's just document that you
 have to set PYTHONPATH. (The name `init-dev-env` is mostly unknown to
 Google--is there some other name commonly used by other projects?)

 obfsproxy [https://gitweb.torproject.org/pluggable-
 transports/obfsproxy.git/blob/5be824934d4f05fe71403d70f15f7450be5a4350:/bin/obfsproxy
 does a trick] to insert the directory containing the executable to
 `sys.path`. I would consider such an approach acceptable. (But sadly would
 that little code block have to be duplicated in every program, since it
 needs to run before the common library is available?)

 The above comments apply to the client programs. Having to set PYTHONPATH
 only for running the facilitator programs is far less annoying, I'm
 completely fine with it.

 Having code duplication sucks (thus this ticket), but the current setup
 has these nice properties:
  1. You can download a single `.py` file and run it standalone.
  2. You can run from a source checkout.
  3. Installation is super easy on all platforms.
 Number 1 I don't care about at all. Number 2 is nice but I'd be willing to
 give it up if there are sufficient other benefits (elimination of code
 duplication being the most obvious benefit). Number 3, in my opinion, can
 change from "super easy" to "easy," where "super easy" is "copy some files
 to bindir" and "easy" is "copy some files to bindir and copy some other
 files to the platform-specific library directory."

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6810#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online