IDAES/idaes-pse

Reorganize ideas-ext installation

Closed this issue · 1 comments

There are a few issues the the idaes extensions install:

  1. You can't have more than one version installed at a time, so it you want to use multiple versions of IDAES in different environments, you have to reinstall the extensions when switching back and forth. Or you have to know about the secret IDAES_DATA environment variables that allows you to use alternate idaes_data_directry locations
  2. We have a shared ipopt library and header files. This can be used to build things like Cyipopt. Currently they are just in a tar file in the install location. We really need to establish a standard directory structure and extract them.
  3. We have data files now for Helmholtz EoS component parameters. Currently I'm just sticking them in the bin directly because that's all I have.

I'm proposing the default idaes_data_directory stay the same $HOME/.idaes on not Windows and %LOCALAPPDATA%\.idaes on Windows. This is overridable by setting the IDAES_DATA environment variable.

Inside the data directory we install the extensions in a subdirectory ext-{x}.{y}.{z}, so each version gets its own directory. The extensions never change once a version is released, so once a version is installed it is done. If you want to reinstall just delete the ext directory and reinstall. This will fix the problem in issue #850 and permission problems with install if a file happens to be in use.

In the ext directories we just have the usual

  • bin
  • lib
  • include
  • share (probably add data file here)
  • src (maybe)

Another option is pip, but I don't think I can manage to compile the manylinux compliant build https://peps.python.org/pep-0599/. If someone wants to give that a shot, they can have at it. It may be possible if you can statically link Fortran, BLAS and LAPACK. I'm not totally sure if it is possible. You can't statically link the standard C and C++ libraries because Ipopt needs to dynamically load other libraries (like the external functions and possibly other solvers). So I'm not sure that you can statically link fortran and not C. I was able to build a fully statically linked Ipopt, but it could not use AMPL user-defined functions.

Also possible is something like Flatpak https://flatpak.org to reduce the number of builds and make distribution easier.

I think the long term solution is to figure out how to distribute the binaries with pip or conda. The short term solution is just documentation (issue #1078). I'm going to close this.