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:6 dcf]:
 > Can you explain the purpose and benefits of the versioneer library?
 >

 It automates version numbers from git tags, so you don't need to keep
 editing the version file. It generates versions like 1.3+git1fce958 (like
 `git describe`) for non-tag commits. I copied the idea over from
 obfsproxy.

 > I wonder if it's possible to flatten the taxonomy a bit. I think I
 prefer
 > {{{
 > import flashproxy
 > flashproxy.parse_addr_spec()
 > }}}
 > over
 > {{{
 > from flashproxy.common.util import parse_addr_spec
 > parse_addr_spec()
 > }}}
 > Three levels just feels a bit too deep. I'd lean toward packages
 `flashproxy` and `flashproxy.fac`. What do you think?
 >

 How about 2 levels so flashproxy.{keys,util,proc,fac} - I originally had
 this split, I only went to 3 levels to work around some python paths
 issue, but that won't be necessary if I merge the fac library into here as
 suggested below. (I could also merge proc.py/util.py together.)

 > I think it's fine to ship the facilitator library functions in the
 client tarball, so there's no need for a split between common and non-
 common functions.

 OK, it will make the packaging smaller as well. The original split was
 because I thought you wanted to keep the client binary distribution as
 small as possible.

 Replying to [comment:7 dcf]:
 > `make install` was a sticking point the last time, too. Maybe we should
 just remove the `install` target? It can't be that very many people are
 using `make install` or even using the client packages. Or do you need
 `make install` for the Debian package?
 >
 > Your idea of using `setup.py` only for installing the library was a good
 one. It avoids the bugs we found earlier in trying to use `setup.py` to
 install binaries and man pages, and to build tarballs. Can we just do the
 `python setup.py install` thing on `make install` automatically? I know
 it's possible to pass the bindir and destdir in this way.

 Yes, that's fine, and here we are going into packaging territory so I've
 written some more background info FYI on #9668

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6810#comment:8>
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