support for containerized installs

[ipelupessy]

I would like to gather all issues/ needs/ ideas for containerized AMUSE installs here

[ipelupessy]

#214 allows startup of codes in a singularity container from outside it (at least in a clunky way). This needs to be supported better:

• maybe allow current detection of presence of worker etc to look inside container?

[ipelupessy]

run_command_redirected.py maybe installed/ and used as binary. Currently its location ends up in the command line by importing and looking at file property. This would not work for cases where the AMUSE install from which the worker is used is different than the local install (thus also not for containers).

[gekaremi]

Will be it something like https://github.com/evbauer/MESA-Docker ?

If will, maybe it is useful to maintain two versions: full, with all possible modules, including heavyweight as MESA, and lite, with minimal set.

So, such container edition will remove need in binary release and possible can make amuse available on not-so-open OS

Its look like there already was such attempts, but unsuccessful
https://github.com/mrteetoe/docker-amuse
https://hub.docker.com/r/mrteetoe/amuse/

[ipelupessy]

@gekarmi: we are not sure yet about the exact form, ie whether it should be an a way to distribute the binary, or there should be a more extensive container (with development tools), or a way to isolate (the prereq of ) different community codes. There is a minimal amuse install (framework+ 3 codes) singularity image:

singularity pull singularity pull shub://ipelupessy/amuse-singularity:42.3

(if you have singularity installed)
this can be used as binary distribution (running amuse scripts), or with #214 to start single codes, with from an standard AMUSE install (at some point may be useful way to start codes on remote machines)

in other words if you have more ideas, list them here..

[gekaremi]

[disclaimer: i am not really any sort of developer, just computational astrophysics script kiddie, so there are high probability thats all are totally wrong]

whether it should be an a way to distribute the binary

Oh, sorry for my poor english and hopeless writing skills in any language, it seems I wasnt made my words clear
Container(in most usuall forms, from my newbie experience) will be successor of possibly al features of binary releasel(except some really exotic case, as very stricted system)
It will make install as simple as possible. Because is pretty hell now. And it isnt amuse fall, at all. Reasons are all diiferent of versions of libraries in different linux distribution, python enviroments and distribution channels
Great recent story when apt-installed pip 10 in debian-based ask people to literaly destroy themself pypa/pip#5221 pypa/pip#5240
(so, https://xkcd.com/1987/)
And maybe simpliest way to deal with all this mess is put right distro with right versions of libraries in container and forget about it
(and again https://xkcd.com/1988/ )
This will be overhead and slowdown, but maybe help with that problem and also help mantain different amuse in one machine, qick deploy %and other default containers pros and cons%

Finally, IMHO, binary in container is pretty useless, because destroy advantages of binary release itself(just executable file, small size, no need to any installation, clear and small dependences...)

Thank you for your time and attention!

[ipelupessy]

https://github.com/amusecode/amuse-containers