On 06 Aug 2013, at 16:05, Fotis Georgatos wrote: > >>> 5) better organize build environment variables >> [...] >> The target to fix here is >> https://github.com/hpcugent/easybuild-framework/issues/604 . >> [...] >> I agree this is an important issue, but since we (nor our users) are running >> into problems related to this, we don't spend time on it for now. > > I am a little bit surprised about that: > - The users at Ghent don't find themselves in surprise when fi. > MPICC is defined to what corresponds to a GCC build instead of icc etc?
Most users just ask us to build stuff. Also, I'm not saying they're not running into it. But they're not complaining about it (to us). Maybe they're using the GCC compiler provided by the OS, or use mpiicc instead (which uses icc instead of gcc, iirc). > >>> 6) Implement common HPC policies > [...] >> If someone comes up with (versioned) HPCBIOS easyconfigs that group together >> the must/should elements of particular HPCBIOS policies, we'll be happy to >> include them in the easyconfigs repo and in the next EasyBuild release. >> I don't see why not. > > Nice; fyi. I consider them in prototype most yet but, > in practice I have started deploying them in production this month > (ie. good enough to get some automation work done nicely). I suggest you issue PRs for the ones you feel are ready/complete. > >> My proposal: version these easyconfigs by date (e.g. >> HPCBIOS_Bioinfo_2013-08.eb), and maybe provide separate ones for MUST and >> MUST+SHOULD... > > OK, I get it: > - versioning should be visible in the name, good point. > - MUST vs MUST+SHOULD, alike biodeps vs biodeps-extended, alike R-bare vs R > etc. > >> Having some kind of standard w.r.t. naming of easyconfigs and organization >> would really help imho. > > Yes, I am already going towards that direction, see naming scheme here: > https://github.com/fgeorgatos/easybuild.experimental/tree/master/users/fgeorgatos/HPCBIOS > What would be your desires? can you propose other suggestions, > to make them suitable for your needs? > > eg. Pick to comment for a start Math, Debuggers, LifeSciences. * missing versioning (in filename), e.g. should HPCBIOS_Math-20130717 -goalf-1.1.0.eb * "As of May 2013, goalf/1.1.0 loads all of:" => comment is weird, since what's in goalf/1.1.0 will never change; I'm not even sure why a comment that lists goalf elements is included... * HPCBIOS_Math-20130717 -goalf-1.1.0.eb uses PETSc that depends on Python 2.7.3, which is not the latest Python version (at the time of 2013-07-17) If you're going to version these easyconfigs by datestamps, you should probably try and use the latest version of all software packages at that point in time... If not, use x.y.z versioning, to avoid users expecting the latest and greatest stuff. * some elements are commented out because of dependency issues or because easyconfigs are missing; these issues will have to be resolved first before you can do a PR > >>> 7) Common list of (bioinformatics?) applications of interest > [...] >> The ideal situation would be that: >> >> a) someone who starts working on some app opens an issue first expressing >> interest, and stating that he has started working on it >> b) someome who wants to start working on some app checks whether an issue is >> open first >> >> However, this requires discipline, and there's no way to enforce people to >> do this (and hence, we don't do it ourselves). > > Yeah, I understand in theory that's how it should be done but I find first > myself not doing it :) > >> Maybe we'll just have to live with it, and use it to our advantange, i.e. if >> it turns out that two people are working on the same stuff, review each >> others work, find a common ground and then either work together on it or let >> one of both finish the job. >> >> I'm afraid there's no silver bullet here... >> >> What might help is an eb feature that allows one to crawl all EasyBuild >> (experimental) repositories and branches in search for easyconfig files for >> a particular software package/version. >> But again, that requires discipline on the user: search first, start working >> then (after opening an issue so others are aware). > > One of the early things i had toyed with (that funky `module search`, > remember?) > was to automatically do a `find` over a range of (mostly git) repos with > easyconfigs; > it worked quite well and helped me to organize bits on my end. > > What I was hoping for, would be as simple as a wiki table (that functions as > a real wiki!) > on which we can all start adding our wishlist, adding eg. initials at the end. > That is super-useful when you have a half-baked easyconfig/easyblock and you > want > to invite people to help or test, because then you know exactly who cares > about it. Some things: requires discipline of every contributor, or it won't work. And if we're not forced, we will end up not doing it (trust me). > The other alternative is what I have been doing with opening issues over > lists of applications, > example https://github.com/hpcugent/easybuild-easyblocks/issues/82 , > but that is a little bit embarrassing, because it is as if we go begging... :) That's fine, imho. But same problem remains... > Anyway, as long as you remain cool about it we can keep going like this for a > while. It's unfortunate that sometimes we end up discovering double efforts, but it's not always work that's lost entirely imho. Having someone that can review your work because they really know what's going on can be very useful! regards, Kenneth
