Hi Kenneth, Thanks for that! It turns out to be a bit simpler, since CMakeMake is itself a subclass of ConfigureMake, so I don’t even need to use multiple inheritance - I just need to explicitly specify when I want to use the ConfigureMake version of a method that differs materially between ConfigureMake and CMakeMake.
Cheers, Ben > On 10/01/2015, at 3:56 am, Kenneth Hoste <[email protected]> wrote: > > Hi Ben (& Jens), > > On 09/01/15 15:03, Jens Timmerman wrote: >> Hi Ben, >> >> On 09/01/15 00:19, Ben Roberts wrote: >>> Hi all, >>> >>> >>> Is there a convenient way to do things so I can have both EasyBlock modules >>> in place at once? I don’t suppose I could call both EB_GROMACS, and it’s >>> not clear that names such as EB_GROMACS_PRE46 and EB_GROMACS_POST46 will >>> have the desired effect either. Thoughts? >>> >> You can use the self.version inside an easyblock, >> so you could have one easyblock that behaves differently depending on the >> version in the easyconfig. >> See SAMtools for an example [0] >> >> One fun (nasty?) think you can do with python is multiple inheritance, so >> you can have the EB_GROMACS class inherit from both configuremake and >> cmakemake, or maybe inherit from EB_GROMACS_PRE46 and EB_GROMACS_POST46 and >> in the init you could call the super depending on the version. >> >> so something like this: >> >> class EB_GROMACS(EB_GROMACS_PRE46, EB_GROMACS_POST46): >> def __init__(self, *args, **kwargs): >> if LooseVersion(self.version) < LooseVersion(4.6): >> EB_GROMACS_PRE46.__init__(self, *args, *kwargs) >> else: >> EB_GROMACS_POST46.__init__(self, *args, *kwargs) >> >> >> I'm sure there are other ways to do this, but this looks the most simple and >> modular at the same time to me. >> If the internal changes are pretty small you can do it the way samtools does >> it and have version checks scattered trough the easyblock. >> >> [0] >> https://github.com/hpcugent/easybuild-easyblocks/blob/0dfed6cbeeeef56c4c21bc5397623cd91b606ff4/easybuild/easyblocks/s/samtools.py > > I have yet to see an example of software in which it's too complex to not > keep support for different versions with (slightly) different build > procedures in a single easyblock. > > So, I support Jens his proposal of combining multiple inheritance together > with version checks using LooseVersion. > > I wouldn't introduce two artificial EB_GROMACS_PRE46 and EB_GROMACS_POST46 > easyblocks though, since that is likely to involve quite a bit of > copy-pasting of code, which we work hard to avoid. > > So, you probably want something like (quick example, didn't try/check the > syntax): > > class EB_GROMACS(CMakeMake, ConfigureMake): > > def configure_step(self): > if LooseVersion(self.version) < LooseVersion(4.6): > # versions prior to v4.6: use configure script > ConfigureMake.configure_step(self) > else: > # recent versions: use CMake > CMakeMake.configure_step(self) > > > It's not unlikely that other parts of the code (build_step, sanity check, > etc.) remain pretty much equal, hence my preference to keep things nicely > together in a single easyblock. > > If we end up with a (couple of) cases where things get too messy, we can add > support in the framework for also considering the software version to select > a particular easyblock, rather than just the software name (see also > https://github.com/hpcugent/easybuild-framework/issues/681). > > So, rather than only trying 'EB_GROMACS' when installing GROMACS v4.6.x, the > framework would first try and look for an easyblock for something like > 'EB_GROMACS_4_6', then 'EB_GROMACS_4', then 'EB_GROMACS'. Things get more > complicated though, since the 'EB_GROMACS_4_6' should also be used for > GROMACS v4.6, v4.7, (v5.x?), etc. So it's definitely not trivial... > > Even in that case, the different easyblock classes would like be housed > together in a Python module named gromacs.py, to ensure stuff nicely sticks > together. > > > regards, > > Kenneth
