[tor-bugs] #7883 [Flashproxy]: Consider and potentially implement the integration of pyptlib in flashproxy

[Tor Bug Tracker & Wiki]

#7883: Consider and potentially implement the integration of pyptlib in flashproxy
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:  asn           
     Type:  task        |         Status:  needs_revision
 Priority:  normal      |      Milestone:                
Component:  Flashproxy  |        Version:                
 Keywords:              |         Parent:                
   Points:              |   Actualpoints:                
------------------------+---------------------------------------------------
Changes (by asn):

  * status:  needs_review => needs_revision


Comment:

 Replying to [comment:3 dcf]:
 > The patch looks overall nice.
 >
 > The changes in `flashproxy-reg-email` don't look right. That program is
 not a transport plugin and it shouldn't be calling `pyptlib.client.init`.
 `flashproxy-reg-email` is forked by `flashproxy-client` and inherits its
 environment variables, including `TOR_PT_STATE_LOCATION`, which it uses.
 `flashproxy-reg-email` shouldn't be doing the whole PT negotiation.
 >

 Oh, I see. Well, I guess in this case, it would make sense to leave
 `flashproxy-reg-email` intact (as it was before my changes) and assume
 that the PT negotiation was done by `flashproxy-client`. I will update my
 branch soon.

 > I thought about keeping a copy of pyptlib in the flashproxy tree. The
 trivial thing doesn't work because there is an extra level of `pyptlib`
 directory before reaching `__init__.py`.
 > {{{
 > $ ./flashproxy-client
 > Traceback (most recent call last):
 >   File "./flashproxy-client", line 23, in <module>
 >     import pyptlib.client
 > ImportError: No module named pyptlib.client
 > }}}
 > If we include pyptlib in this way, then there is the problem of what
 `make install` should do. It can copy its own copy of pyptlib to
 `/usr/local/lib/python`, but there might already be a copy of pyptlib
 there.
 >
 > I guess the best thing in the log run is to require pyptlib to be
 installed already. To that end, in your branch would you add links and
 instructions for installing pyptlib to `README` and to a message that gets
 printed when a `pyptlib` import fails? I'm still not totally decided how
 to handle all this.

 I see your concerns and I agree. For pyobfsproxy, I have decided to assume
 that pyptlib is installed already.

 For flashproxy, I think assuming that pyptlib is present makes a bit more
 sense, since `flashproxy-client` and `flashproxy-server` will only be used
 by clients which should be using bundles anyway. So the bundle maker has
 the responsibility of installing pyptlib properly. For advanced clients
 who want to setup the thing on their own, we should update the README
 appropriately.

 In any case, the decision is up to you on whether you want to use pyptlib
 or not. Maybe you want to skip it, till pyptlib gets some more features
 (like Extended ORPort support), and that's fine.

 I plan to update the README, and add an import error message, soon.

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