@cmacmackin Chris, thanks for making the intial push with flatpack! I encourage the idea of using Python as the principal language for flatpack. I also see this as a daunting task, especially if the ultimate goal is seamless Fortran software portability across platforms (yikes). Another package manager that could be used for initial design ideas is that of Julia language http://julia.readthedocs.org/en/latest/manual/packages/, which also pulls packages from GitHub repos.
I forgot to mention that I will be willing to contribute where possible.
Yeah, it's a big project (which is why I'm hoping to get plenty of collaborators). That said, the developer of software will still have to bear the bulk of the responsibility for portability. I'm envisioning this as being a bit like Arch Linux's AUR, whereby all software is installed at the user's own risk--although we could certainly establish a route to flag broken packages for removal from FLATPack's database. The goal of FORD will be to provide a framework for distribution of packages which will allow package maintainers to specify how the software should be built for different platforms.
Some more things to consider--sorry still nothing concrete:
- It strikes me that what we are doing is similar to the role played by portage in Gentoo Linux. I don't suppose anyone here has any experience with Gentoo/portage which might provide some insights? Other than knowing that it is a package manager which compiles from source, I know nothing.
- It could potentially be useful to integrate FoBiS by @szaghi. While bigger libraries would probably need more elaborate build systems, for many FoBiS is sufficient and this could make packaging simpler for people.
Just a couple of random thoughts, which may or more likely may not have value.
I really like the way homebrew does package management. It’s Ruby based, but something similar could be cooked up in python:
- stow-like deployment of symbolic links; packages are installed in a special location (for homebrew
/usr/local/homebrew/Cellar/<package-name>/<package-version>) that is out of the way, not on the PATH etc. and then symbolic links are created in/usr/local/<lib|bin|include|share|etc> - Package build & installation instructions are kept in formulas which are kept under version control
- Installation can be configured to go elsewhere besides
/usr/local/ - Encouraged to install to somewhere without the need of root privileges by making
/usr/local/userrwxor installing elsewhere
I do not know portage. I use yaourt on my Arch Linux. The PKGBUILD syntax is very simple and (I think) it can give high flexibility fot building (on the fly) and installing the package. The homebrew logic is very nice, I vote for something similar. Some
/usr/local/flatpack/... with sym link in PATH-visible. Something similar to the python site package. Moreover, the homebrew formulas seem very nice (with the versioning plus). As the integration with FoBiS.py I suggest more careful: I think it is better to integrate first well established building systems (Make, CMake, Scons,...) and in the future support integration with FoBiS (that is very immature). I finally suggest to @cmacmackin to create a team for FLATPack thus we can join you.
I really like the idea of a homebrew-like package manager and I share the importance of the points already mentioned.
On my side I just wanted to say that I wrote some time ago a very very very primitive version of a package manager that I use to install a number of Fortran packages, personal software I wrote and other useful numerical stuff. You can find it on my page:
https://github.com/aamaricci/Bootstrap-libs
It is a bash script that retrieve, clone and install packages that I keep in a suitable form on my page. On one side this is handy because everything is based on git, one only need to provide a suitable Makefile. The bad thing is that each package needs some kind of repackaging to fulfil few rules. You can take a look at the repackage of Lapack,Blas,etc..
I'd like to raise two points:
- what is the kind of software or packages you think could be included in the manager repository?
- how do we deal with the .mod problem? Usually I use the CPATH env variable, but this is working only for Intel fortran compiler. GNU needs to explicitly state the path to .mod dir.
I've put together an outline of how I think FLATPack could be organized. You can find it in the repository. At present only stubs are present, hopefully with enough documentation that you can get an idea of what they'll do and how different classes will interact with each other. All of this is highly preliminary and any thoughts, advice, or feedback would be appreciated.
For those that were interested in this project, I have resurrected it as a repository for the Spack package manager. At present there are only a few packages in there, which I have needed for my own work. At some point I will come up with a procedure for people to add their own packages to it using pull requests and a continuous integration system to check that their packages actually build. I will also look to have a means to generate an HTML package index. For now, if you have any packages you'd like to add, feel free to go ahead. The big numerical codebases (LAPACK, PetSc, FFTW, Trilinos, etc.) are already present in the built-in Spack repository.