A way to get setup.py to create links instead of copy

[Geoff Bache]

On Nov 9, 6:33 pm, Steve Holden <st... at holdenweb.com> wrote:
> On 11/9/2010 4:18 AM, Geoff Bache wrote:
>
> > Hi all,
>
> > One of the things I've always loved about Python (having come from
> > compiled languages) was the lack of an extra step between changing my
> > code and running it.
>
> > On my current project, however, I find that I have to install my
> > Python code with setup.py before it will run. Being used to not having
> > this step, I easily forget to run setup.py install before they will
> > run, and then spend time wondering why my changes didn't work.
>
> > So I went into the target directory and replaced the copies with
> > symbolic links back to the original code. This felt like a hack but
> > does mean I don't have to install the whole time any more.
>
> > I wonder if there is some standard way to deal with this situation?
>
> Yes, there is. It involves (to a first approximation) understanding the
> role of sys.path, and its relationship with the PYTHONPATH environment
> variable. In brief, this tells the interpreter where to look for modules
> when it is importing.
>
> Installation with setup.py is normally reserved for a fairly permanent
> insertion of the code into your Python distribution, which might have
> added it for all users. If this is an issue you may want to undo the
> installation manually by removing its additions to your Python's
> Lib/site-packages directory.
>

Hi Steve,

I think I understand this stuff fairly well. I have my own Python
installation (using virtualenv) so I'm not affecting anyone else.

The problem is that my program runs from the command line, and is
tested via other programs that call it as a subprocess, and don't
expect to have to invoke Python explicitly. It does not work with the
default Python on my system, which is a too old version, so relies on
the "#!" line at the top to be correct. As I cannot hardcode this in
my source tree, it seems difficult to make it runnable from the source
tree.

Incidentally, I'm interested that you say setup.py is normally
reserved for a permanent installation. I've run into many Python
programs, including quite well known ones, which did not appear to be
runnable directly from the download or source tree, but required
running setup.py before they would work.

Regards,
Geoff