Skip to content
This repository has been archived by the owner on Jan 31, 2024. It is now read-only.

Add automatically path for i-PI from all scripts in bin #106

Open
mahrossi opened this issue Jan 29, 2016 · 7 comments
Open

Add automatically path for i-PI from all scripts in bin #106

mahrossi opened this issue Jan 29, 2016 · 7 comments

Comments

@mahrossi
Copy link
Collaborator

I suggest to add the following lines:

dir_root = os.path.realpath(
os.path.join(os.path.dirname(os.path.realpath(file)), '..'))
if not dir_root in sys.path:
sys.path.insert(0, dir_root)

to all scripts in the bin folder, not only the main i-PI -- so that all executions happen seamlessly. Agreed? If so I will proceed to do it.

@mahrossi mahrossi self-assigned this Jan 29, 2016
@ceriottm
Copy link
Collaborator

@ondrej and @thomas have done that path juggling modification so I am not
100% of the implications. I'd wait for them to comment.

On 29 January 2016 at 16:57, Mariana Rossi notifications@github.com wrote:

I suggest to add the following lines:

dir_root = os.path.realpath(
os.path.join(os.path.dirname(os.path.realpath(file)), '..'))
if not dir_root in sys.path:
sys.path.insert(0, dir_root)

to all scripts in the bin folder, not only the main i-PI -- so that all
executions happen seamlessly. Agreed? If so I will proceed to do it.


Reply to this email directly or view it on GitHub
#106.

@mahrossi
Copy link
Collaborator Author

👍

@OndrejMarsalek
Copy link
Collaborator

To be honest, I am not a fan of that path injection even in the main program - it should simply never be needed. You source the env.sh (think GMXRC or similar environment settings files other programs use) and you are all set - both your PATH and PYTHONPATH get updated so that you can both call the executables and import the ipi package. This is no more "work" than adding the bin directory to your path by hand, but either of those is more convenient than calling everything with a full path. I don't think it would break anything, but it is just more code that gets in the way and does not look very nice. The env.sh has the advantage of being able to import the ipi package from any code, say when you have a custom tool that just uses i-PI for something specific.

That being said, if you insist, I will not try and stop you :-) I would be interested in what the use case for this is, though.

@OndrejMarsalek
Copy link
Collaborator

BTW, Github technical tip - you can quote a code block without having the formatting messed up using triple backticks. If you add the name of language, you even get syntax highlighting!

https://help.github.com/articles/creating-and-highlighting-code-blocks/

# Check that we have the import path for this i-PI set and if not, add it.
dir_root = os.path.realpath(
               os.path.join(os.path.dirname(os.path.realpath(__file__)), '..'))
if not dir_root in sys.path:
    sys.path.insert(0, dir_root)

@mahrossi
Copy link
Collaborator Author

Hi Ondrej -- I know, I can certainly set my paths, source env.sh, etc. However, I've gotten reports back from quite a few people complaining they can't run this or that routine. The reason being that since the main code has those lines in, I think people just use it and don't notice. Then when they use another one of the routines in bin, they get stuck because they never set the paths. So, I was just thinking about minimizing complaints with something that should ideally work out of the box for a more pleasant experience. If you want to take it out of the main code, by all means go forward. I'd say better all or nothing.

@mahrossi mahrossi removed their assignment Jan 30, 2016
@OndrejMarsalek
Copy link
Collaborator

OK, I see what you mean. This is relevant also to the situation after release, of course. For some reason, I was certain that the instruction to source env.sh was in README.rst, but it does not seem to be. Hmm, I might have an unfinished update somewhere :-)

My preference would be to document env.sh in README.rst as the standard way to make everything work, as this is how everyone does it anyway, and get rid of the injection, if it has the potential to confuse people. If you guys overrule me on this, I will (probably) not cry, though ;-)

@OndrejMarsalek
Copy link
Collaborator

Note that as the executables are simple Python programs, they can be simply copied elsewhere (say, when modifying them), but will "magically" stop working if the ipi package is made available using the injection (because it relies on relative paths). With the Python path updated using env.sh, it will work just fine.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants