FSI_tools module installs to /usr/bin
dcjud opened this issue · 6 comments
[ issue title should say "Python modules install to /usr/bin" - it's not just FSI_tools ]
Building v7.5.1 on Linux (Slackware 15.0) installs three subdirectories to /usr/bin:
/usr/bin/FSI_tools/
/usr/bin/SU2/
/usr/bin/SU2_Nastran/
These appear to be Python modules. Is this install location intended? Perhaps I missed an important build step.
The difficulty is that this conflicts with the Linux filesystem hierarchy: "4.4.2: There must be no subdirectories in /usr/bin."
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s04.html
... and results in complaints when building e.g. a Slackbuild package.
In any event, /usr/bin is not where Python modules belong.
Minor problem, I know, but the fix is probably pretty easy: Install these modules using pip. I believe pip is supposed to know the correct place to install modules. For example, on my system, pip installs them to /usr/lib64/python/site-packages, which seems to be on the default module search path.
Side benefit: one can dispense with setting SU2_RUN and PYTHONPATH in ~/.bashrc. And PATH in any event, since /usr/bin should already be in the path except in rare cases.
I would offer to implement this but surely there are others more familiar with meson+ninja ... but if need be, I'll give it my best shot.
- JM
Bug report checklist
Please make sure that you have followed the checklist below, many common problems can be solved by:
- Consulting the build instructions (https://su2code.github.io/docs_v7/Build-SU2-Linux-MacOS/).
- Looking for similar problems on GitHub or CFD-Online (https://www.cfd-online.com/Forums/su2/).
- Updating to the newest version of SU2 (either develop, master, or the pre-built executables https://su2code.github.io/download.html).
Desktop (please complete the following information):
- OS: Linux Slackware 15.0
- C++ compiler and version: gcc 11.2
- MPI implementation and version: mpich 4.1.2
- SU2 Version: v7.5.1
Maybe we can just change the default instal prefix to something legal.
As long as the binaries go to $prefix/bin and the python modules go somewhere else, the problem will be solved!
Some of the python scripts are meant to be used as executables, not just imported.
Is usr/local/bin a better prefix?
I think the way the prefix is set up is fine. My suggestion is more about where things go under $prefix.
For python scripts meant to be used as executables... I'd put these directly under $prefix/bin, e.g. on my system, /usr/bin/foo.py and be sure that foo.py has execute permission.
Python modules meant to be imported ... I'd put these in /python3.x/site-packages or let pip decide where to put them. So foo.py could end up in two different places, I guess.
Concrete example: I just installed and ended up with:
/usr/bin/SU2_Nastran/
/usr/bin/SU2_Nastran/pysu2_nastran.py
/usr/bin/SU2_Nastran/__init__.py
Instead, a better setup might be:
/usr/bin/pysu2_nastran.py (with mode 755)
and
/usr/lib64/python3.9/site-packages/SU2_Nastran/
/usr/lib64/python3.9/site-packages/SU2_Nastran/pysu2_nastran.py
/usr/lib64/python3.9/site-packages/SU2_Nastran/__init__.py
Whereby /usr/lib64/python3.9/site-packages is right for my system, but other systems will have their own place to install modules. That's where I suspect pip might be helpful. Perhaps it could be figured out from sys.path, though not sure how portable that is.
This is an easy fix for someone who understands the build/install process well (and that's not me). But if nobody steps forward after a week or three, I'll give it a try anyway.
TBH with you I'm not very keen on changing the installation process, it has been working fine, and it's a pain to support the community when things like this start failing on university clusters and things like that.
Well, if it works, it works. I'll close this out.