Exaproxy makes false assumptions

[GoogleCodeExporter]

What steps will reproduce the problem?

1. $ sudo pip install exaproxy
2. $ exaproxy -h

What is the expected output? What do you see instead?

I don't know what a running exproxy looks like, but I see this instead:

 $ exaproxy -h
 /usr/bin/pypy: No module named exaproxy

What version of the product are you using? On what operating system?

Exaproxy 1.0.3 on Python 2.7 on Linux 3.2.0.

Please provide any additional information below.

The exaproxy script install by pip makes an assumption (or several such) that 
it shouldn't make, namely that “Oh, pypy is installed so I don't give a damn 
that the user used python 2.7 to install me!”…

Other scripts from other modules installed by pip knows what version of python 
was used to install it.  Exaproxy ought to know too.

Original issue reported on code.google.com by kl...@seistrup.dk on 7 Jan 2013 at 2:25

[GoogleCodeExporter]

Oops, thank you for reporting the issue and sorry for the delay in noticing you 
did ... we do not use pip when developing and are simply running exaproxy from 
the extracted tarball, so this bug was never spotted. We will address it, I am 
not sure how yet, but it may mean trying to determine the python version use 
from the path of of the library ...

It seems the code use to allow to decide which interpreter to use does not work 
as expected as you should be able to force the interpreter using 

> INTERPRETER=python2.7 exaproxy

we will get on fixing this issue, and send you a corrected version of the 
script should you want.

Original comment by thomas.mangin on 19 Jan 2013 at 10:30

• Changed state: Accepted

[GoogleCodeExporter]

Thanks.

As a hint I've attached the script that gets installed by zerobin (arbitrarily 
chosen, other scripts have a similar structure) and that might get you going.

Original comment by kl...@seistrup.dk on 19 Jan 2013 at 3:40

Attachments:

• zerobin.py

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thank you for the upload, I noticed it after fixing the issue. This however 
uses the entry_point feature of setuptools (the script is auto-generated) 
however setuptools uses eggs and install the etc content within the egg which 
is an issue (and I could not find a way around it), so I used another method. 
The archive now contains a new startup script, which will be updated with the 
right interpreter by distutils (it is a builtin feature) on installation.

The detection of the etc folder _may_ however not work as was previously 
(worked on my virtualenv but not on my mac without it) so you may need to 
hardcode the path to the redirector script even it you are not using it. I will 
fix in 1.0.5 - but I could only  see the issue once I could use pip, at which 
point the program was already available on pypi.

Please let us know if this does not fully resolve the issue to your 
satisfaction.

Original comment by thomas.mangin on 19 Jan 2013 at 8:43

• Changed state: Fixed