Hi Todd, Jack, I’ll do top-posting for change :), and keep the relevant bits visible below.
The unfortunate issue with letting R handling its dependencies downloading on its own is, that it turns difficult to ensure consistent environment across sites: * build reproducibility is shot in the foot, since you will rely on external downloads * algorithmic reproducibility is shot in the head, since versions can creep forward AFAIK, cases like with R Bioconductor are hopeless, because these fellows are moving in a totally different angle, than people that wish to rely on artefacts (repositories) and the view that most EasyBuilders have, which is that of bit-accurate rebuilds. The concept of using symlinks to activate/deactive software components, though, is a very valid one and not all that remote from what was discussed during a spring 2013 hackathon in Cyprus, about trying out “Stowed toolchains/bundles” : * ie. let many module versions exist and create mix’n’match symlinked metamodules If you read about “Stow” tool on GNU’s pages you will probably realise this option: https://www.gnu.org/software/stow/ fi. this technique would allow to trim down HPCBIOS_Bioinfo inflated 70+ modules bundle, down to a dozen AND permit extensions management in a way similar to what you describe. This may prove to be an essential method to let $PATH, $LD_LIBRARY_PATH etc to breath, look reasonable again & give users freedom to choose what they wish included and not. After all, it IS cheaper to manage a symlink farm than a bunch of modulefiles! To summarise: using symlinks may prove to be a reasonable approach to deal with complicated extensions or modules sets, although it is not clear yet what may be the side-effects of applying this logic universally. I’ve used R as an example, but the arguments may well apply for Python, Perl, Ruby, etc. (claiming no expert in any of these categories) I’d be interested to hear more about Spack’s experience/insight on the matter. cheers, Fotis On Apr 2, 2015, at 7:01 AM, Todd Gamblin <[email protected]> wrote: > Activation *mostly* just symlinks the external module (and any dependency > extensions) into the python install, but the python package itself can > extend the way activation is done. That is used to provide some custom > logic for merging easy_install.pth files and other things that would > otherwise conflict within the same prefix. So, Spack python installs are > a bit like virtualenvs, in that you can swap versions of extensions in and > out by activating/deactivating them. [.. ..] > With this kind of design, I *think* it would just require overriding > activate/deactivate in the R package, unless R has something MUCH more > complicated than Python. -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
