search

glotzerlab / hoomd-blue

Molecular dynamics and Monte Carlo soft matter simulation on GPUs.
http://glotzerlab.engin.umich.edu/hoomd-blue
BSD 3-Clause "New" or "Revised" License
329 stars 127 forks source link

Please install files inst standard locations #339

Closed joaander closed 5 years ago

joaander commented 5 years ago

Original report by yurivict (Bitbucket: yurivict, GitHub: yurivict).

You install everything under $(PREFIX)/hoomd. hoomd/__init__.py, for example, should be in python directory /usr/local/lib/python3.6. hoomd/FindGit.cmake shouldn't be installed at all (search happens only during build). hoomd/include/hoomd/extern/Eigen shouldn't be installed. Eigen exists in a separate package. cereal also exists as a separate package. Include files should be under include/.

joaander commented 5 years ago

Please understand that the primary use-case of HOOMD is on HPC computing platforms where most users build from source and install to a user-owned directory. All of the behaviors you mentioned are explicit design choices to support those users.

HOOMD-blue is open source: I would accept a pull request that optionally changes installation behavior to meet other use cases - the existing behavior must remain the default to support the large existing user base.

In OS native installs, I use:

#!bash

-DCMAKE_INSTALL_PREFIX=`python3 -c "import site; print(site.getsitepackages()[0])"`

to install to the appropriate python search path.

joaander commented 5 years ago

Original comment by yurivict (Bitbucket: yurivict, GitHub: yurivict).

Having standardized directories doesn't preclude users from installing into their home directory.CMAKE_INSTALL_PREFIX can be redefined to ~/hoomd .

People not inherently familiar with the project can'r be expected to decide which files should go to which directory. This should be done by project maintainers.

joaander commented 5 years ago

Original comment by Mike Henry (Bitbucket: mikemhenry, GitHub: mikemhenry).

This is all while documented here. Note that this section also includes how to install hoomd from conda, which is what I would suggest to a user that doesn't want to deal with compiling source code.

You don't have to be inherently familiar with the project to read the instructions for how to install the software. Perhaps the documentation could add how to install hoomd into the python search path as Josh described.

joaander commented 5 years ago

Original comment by Michael Howard (Bitbucket: mphoward, GitHub: mphoward).

For its current design, HOOMD needs to install all of its dependent headers and CMake files to support external plugin builds. What you are proposing is a very significant change to allow the user to make use of their own versions of libraries rather than the ones that the developers have included via git submodule (this is currently only supported by symlink, I believe). However, this can create huge headaches ensuring that the correct versions are supplied (with fallback to git submodules anyway) and may also introduce difficult to track down bugs due to minor version incompatibilities.

What is your use case that makes you so adamant that the files need to be structured in a particular way? The way things are designed right now, the user just installs HOOMD somewhere, injects it onto the python path if necessary, and never has to worry about how the headers / libraries are organized, even when building a plugin.