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

[Geoff Bache]

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?

Regards,
Geoff Bache

 

[Steve Holden]

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.

regards
Steve

 

[Geoff Bache]

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