patch for python module

Apologies, I meant to reply to this sooner, but I didn't want to step
on any toes. In any case, I think we're now in agreement, nearly!

I have already got lammps working through a python wrapper of my own
(built to support granular simulations in particular), and setup is no
more complex than building lammps itself (no env var hacks.) You can
see my version at:

https://github.com/joe-jordan/pydem

note: I hope the hacks I've added to lammps.py in that repo's
'patches' folder will be unnecessary now.

Having taken a look at your new changes, you aren't far off what I
have in mind; you're just missing the "sudo make install" steps for
c++ and python components. Rather than modify the env vars, why don't
you install the libraries correctly at the locations already in the
env vars like everyone else? (one new make job; install-lib say, and a
setup.py that just installs lammps.py, as before but without the .so)

I'd be pleased if we could enable these two install steps; let me know
if you'd like me to write that patch.

Joe

Having taken a look at your new changes, you aren't far off what I
have in mind; you're just missing the "sudo make install" steps for
c++ and python components. Rather than modify the env vars, why don't
you install the libraries correctly at the locations already in the
env vars like everyone else? (one new make job; install-lib say, and a
setup.py that just installs lammps.py, as before but without the .so)

I'd be pleased if we could enable these two install steps; let me know
if you'd like me to write that patch.

How does install-lib know all the correct auxiliary libs to copy into
site-packages?
Like src/STUBS/libmpi_stubs.so or lib/atc/libatc.so ? Or your libfftw.so
or libjpeg.so if you installed them locally, and they are thus not
already in your LD_LIBRARY_PATH?

When you build the LAMMPS shared lib now, the LAMMPS src/MAKE/Makefile.foo
knows exactly where those libs are and will give an error if they
don't exist.

But once Python tries to load the LAMMPS lib, I don't think it knows where they
are. And you will just get the cryptic CDLL fail-to-load message
unless you have set LD_LIBRARY_PATH correctly.

I'm also not convinced that setting an env variable
once and for all, is less painful than remembering to rerun intstall
scripts every time you edit lammps.py or rebuild LAMMPS.
When I'm developing it seems much nicer (IMHO) to not have to worry about the
re-install after every edit, especially in sudo mode, which I think is
problematic for some users. And sudo has its own problems,
esp if you have multiple Pythons installed (is root's Python the
same as yours?, where is that hidden site-package directory anyway?).

OK, go ahead and push back - I don't think editing env variables is ideal
either, but it is a one-time task, requires no root, is conceptually
simple to get right,
and doesn't touch Python itself.

Any other Python + LAMMPS users out there who want to weigh in?
Axel must have an opinion ...

Steve

How does install-lib know all the correct auxiliary libs to copy into
site-packages?
Like src/STUBS/libmpi_stubs.so or lib/atc/libatc.so ? Or your libfftw.so
or libjpeg.so if you installed them locally, and they are thus not
already in your LD_LIBRARY_PATH?

steve, why did you make .so files out of all those libraries?
why not just add -fPIC to the compilation flags and you can
use the .a files for both cases, the regular lammps executable
and the shared object. *much* less headache and less files
to keep track of.

there is a little fun to be had to make the cuda compiler
accept -fPIC, but that is a different story. :wink:

[...]

And sudo has its own problems,
esp if you have multiple Pythons installed (is root's Python the
same as yours?, where is that hidden site-package directory anyway?).

installing libraries that are not controlled by a package manager
into a system location is a *very* bad idea. as is the "sudo-prefixing".
i could go into an endless rant about how bad this is...

OK, go ahead and push back - I don't think editing env variables is ideal
either, but it is a one-time task, requires no root, is conceptually
simple to get right,
and doesn't touch Python itself.

Any other Python + LAMMPS users out there who want to weigh in?
Axel must have an opinion ...

yeah, i am not a big fan of environment variables either.
in a shared environment, using environment modules,
this is the way to go, but for personal installations
i prefer encoding the search path into the shared object
using -Wl,-rpath,/path/to/where/i/put/my/lammps/libs

this actually allows me to have multiple concurrent
versions of different packages installed and have
executables "magically" pick up the right path.

as for non-root installs. i thought that the build tools
of recent python versions would automatically handle
this by having a "shadow" tree for site-packages in
the user's home directory, e.g. for python 2.7 in:
${HOME}/.local/lib/python2.7/site-packages.

axel.

p.s.: i *rarely* use python, so it is quite amusing that
lammps is now the second project (after VMD), where
people as me for my view on how to do python stuff.