You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as part of an effort to make our ansible roles more "standard", I'm transforming the roles for codes such that they install the codes directly to the /usr/local/ prefix by default (so that all users of the VM/server can use them).
By convention, this is usually achieved by a ./configure --prefix=/usr/local, followed by make; make install.
I notice that i-pi does not seem to have such a mechanism (?)
So, I'm wondering: is it enough to simply copy the driver.x executable to /usr/local/bin/ or do I need to do more?
By the way, it might make sense to call this executable something more specific than driver.x.
The text was updated successfully, but these errors were encountered:
$ i-pi
Traceback (most recent call last):
File "/usr/local/bin/i-pi", line 30, in <module>
from ipi.utils.softexit import softexit
ImportError: No module named ipi.utils.softexit
so I guess, now, sourcing the env script becomes necessary?
Hi @venkatkapil24 ,
as part of an effort to make our ansible roles more "standard", I'm transforming the roles for codes such that they install the codes directly to the
/usr/local/
prefix by default (so that all users of the VM/server can use them).By convention, this is usually achieved by a
./configure --prefix=/usr/local
, followed bymake; make install
.I notice that i-pi does not seem to have such a mechanism (?)
So, I'm wondering: is it enough to simply copy the
driver.x
executable to/usr/local/bin/
or do I need to do more?By the way, it might make sense to call this executable something more specific than
driver.x
.The text was updated successfully, but these errors were encountered: