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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 infinity0):

 Replying to [comment:9 dcf]:
 > I'm relatively open to the idea of using versioneer, but as I say, could
 we deal with it separately? It appears there may be a technical obstacle
 in communicating the version number to `setup.py` from `Makefile`, but
 maybe you have an idea for how to deal with that?

 OK, I'll split this off, and will look into that issue too.

 Replying to [comment:10 dcf]:
 > Sure, but understand I can't merge a patch that breaks `make install`,
 unless we also decide to jettison `make install`. Could you try having
 `setup.py` called automatically? My first concern is ease-of-use from the
 end-user's point of view. Ease for packagers is still important but
 secondary. That is, I would rather have `make install` take one command
 and packaging take two commands, than the other way around.

 `make install` is actually not relevant for the currently-distributed
 packages, which are binary packages. For example, `make dist` does not
 currently package the Makefile, and you are not distributing it in the
 zipball on [https://people.torproject.org/~dcf/flashproxy/flashproxy-
 client-1.3.zip the main website], only in the git repo. I doubt anyone
 actually uses it, so I don't see the importance of not breaking it. For
 our current purposes, we can jettison `make install`.

 However, `make install` *is* relevant and necessary for a source package.
 But, the current Makefile's structure is ambiguous, which is where I think
 your confusion comes from. If we make a source package for flashproxy-
 client (in a separate client-only Makefile), its `make install` should
 *not* install flashproxy-common, since the latter is a separate source
 package to be installed separately.

 Note that this does not affect the existing custom binary packages; you
 still have your easy-to-use run-from-source single package (`make dist`)
 that contains both -client and -common.

 (I also want to create a Makefile.all whose `make install` installs all
 components, which would be useful for the Debian package, but that is
 again an independent concern that doesn't affect anything discussed so
 far.)

 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 the current setup makes it still possible to run from checkout
 if you do 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6810#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs