Hi Stuart! Most people would likely care just about the last paragraph in this email.
On Feb 26, 2015, at 8:26 PM, Stuart Barkley <[email protected]> wrote: > I'm basing my own .eb files off of the HPCBIOS files and once stable > will try the goolf-1.7.20 toolchain. Yes, that’s exactly how it should be done. > Is there a mailing list where HPCBIOS is discussed further? Not yet, but we can make one, if we feel we are a burden to the others here :) If the contribution is in the form of easyconfigs/easyblocks, this list may be the right place. Otherwise, I recommend issuing an issue on github. Basically, the process is RFC-like: - someone comes up with a definition that solves a user group need, somewhere - a second HPC site implements and checks the same definition in some kind of way - cross validation ensures that the whole definition makes some sense, for >1 sites - the result should be pushed out to the community for further usage The process should follow the IETF doctrine: “rough consensus and working code” fi. The following one could easily trigger github issues, by potential users: http://github.com/fgeorgatos/HPCBIOS/blob/master/HPCBIOS_2012-98.rst > At this point, I'm still getting started with this and am looking for > existing knowledge of what are current best practices. e.g. The > suggestion of sticking with gcc 4.8.4 and python 2.7.3 seem > reasonable, but I would like to see more information about why these > specific versions. A pack of reasons for preferring today GCC/4.8.4 are listed in the goolf/1.7.20 intro over here: https://github.com/hpcugent/easybuild-easyconfigs/pull/1294 As regards Python, the information is more anecdotal and requires scrutiny from community. I recall Kenneth once mentioning in this list about a bio package requiring 2.7.3; My memory is dim, it could well be that a kind of Python upgrade is already viable. Be my guest, if you wish so :) > The HPCBIOS .eb files are all quite old in eb-1.6.1. Has Now that the 1.7.20 strains of open source toolchains (goolf and friends) are baked into the next release, it will be a good moment to refresh them. Spring 2015 is a good period for updating them to latest and greatest! ie. the work has already started. btw. It would be very beneficial if more of the open easybuild PRs could get merged in, since that helps testing significantly (and keeping eb author attribution right!). Fotis being specific: Pablo’s recent PRs can help a few others in Life Sciences. > consideration been given to splitting those out of the eb release > process? I could see that these configurations would evolve somewhat > separately from the easybuild process. Yes, I can see how this may eventually happen: - once the noise of discussions fighting dependency hells [1] becomes an annoyance to regular EasyBuild users, that would be the right moment to do that. I think we are not there yet and everyone benefits from the collegiality. Since you seem to come from a Life Sciences background, I recommend you check “biodeps", if you are to mix-n-match HPCBIOS bundles together: https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/b/biodeps/biodeps-1.6-goolf-1.4.10-extended.eb Rational is explained over here: http://hpcbios.readthedocs.org/en/latest/HPCBIOS_2013-01.html ie. Defining and sticking to common fixed versions to avoid Dependency Hells [1] & avoiding version creep/featuritis [2]; that has proven to be a major challenge. btw. If all the above appears like nonsense to you, just try to inject ABySS as an extra member of HPCBIOS_Bioinfo bundle and you will have great Boost'ed fun ;-) best, Fotis [1] http://en.wikipedia.org/wiki/Dependency_hell [2] http://en.wikipedia.org/wiki/Feature_creep -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
