On Thu, 2012-07-26 at 17:07 +0200, Fotis Georgatos wrote:
> Hi there,
>
> sorry for the rant in these couple of days, it won't happen again :-)
> It just happens that we are in a burst of experimentation with the tool
> and we identify all sorts of hick-ups, that occur in our situation.
>
We appreciate your feedback!
Our lead EasyBuild developer Kenneth is currently on a break, but he'll
be back next week, so I expect some replies from him...
>
>
> 1) class namespace
>
> And, in less that 24 hours I can provide an interesting example:
> So, what if I need a module for both "easybuild" and "EasyBuild"?
> https://github.com/fengy-research/easybuild ;-)
>
> In the current setup, that just misses closely a collision in class namespace:
> # class_name = name[0].upper() + name[1:].replace('-','_')
>
> I am suggesting to rename that, for generality, to:
> # class_name = "eb_" + name.replace('-','_') # or, perhaps, "EasyBuild_" (1)
>
>
I see your point and agree, but I'd like to remark that class names can
be completely arbitrary, and set by easyblock='classname' in the .eb
file. The guessing of the easyblock by taking the name is just a
feature.
I'd like to discuss this with Kenneth.
>
> 2) fall-out from the above
>
> Then the following logical consequences exist, as regards easyblocks:
>
> * classnames no longer start with a-z letters (they are *one* set after all)
>
> * placing them in distinct directories a-z is no longer too relevant :-(
> BUT: Is that really a problem? IMHO *NOT*, since easyblocks are not many
> * A motivation exists to actually embed easyblocks class/functions inside
> *easyconfigs*; that is actually good: eg. if/when the "boost" developers
> eventually decide to pick the more decent configure default mechanism, it
> will actually be *possible* to have both v1.50/v1.5X-with-configure modules.
> Currently, I think that's not doable or, am I missing something?
>
We are actually trying to do the opposite, and getting as much as
possible into the easyblocks...
Since our point is to actually distribute our easyblocks, and only a
couple of easyconfigs as references/examples.
>
>
> 3) reduce simple cases to minimal configuration
>
> * Finally, it would be convenient to minimize the number of lines of code
> needed for simple things like the following (can it become 1 line really?):
> ** Boost::make(self): cmd = "./b2 %s" % (self.getcfg('makeopts'))
> ** Pandaseq::configure(self): cmd = os.path.join(self.getcfg('startfrom'),
> "autogen.sh")
>
I do not agree that reducing lines of code like this reduces human
error.
> * Allow to skip certain steps easily (we notice it is often required):
> ** skip_configure=true
> ** skip_make=true
> ** skip_make_installdir=true
See below.
>
> 4) Proposal for small easybuild language extension
>
> And, interestingly, there is a pattern in the following construct:
> (an empty configure and then copy files to destination, before finishing)
>
>
> The interesting part is the for line which does the copy; it'd better look:
> # for filename in sanityCheckPaths['files']:
>
> In that case, we have a pattern that is *very* common across many packages,
> which depend rather on 1 plain Makefile instead of configure.
> Can this be reduced to a single easyconfig line? I think yes.
> *I believe this is worthy of support inside the configuration language.*
>
You are correct to see these recurring patterns, I do not thing a new
configuration option is needed here thought.
e.g. installing binaries is a recurring thing, so we just create this
EasyBlock:
https://github.com/JensTimmerman/easybuild/blob/1035ecore/easybuild/easyblocks/b/binary.py
And using easyblock="Binary" in the configuration file.
You could create e.g., a MakeCopy easyblock which does just what you
suggested, and reuse this everywhere. (and extend it where some special
configuration is actually needed) This would basically be the same as
the Binary one, but without overwriting the make. I guess I will need
something like this really soon, so expect it to be added anyhow.
So, to be clear, we welcome your feedback and encourage everyone to
contribute easyblocks and patches back. So if you add a easyblock like
this, please create a pull request on github, and we'll include it in
our next release.
>
>
> 5) Support for git-supplied software; does anybody else have the need?
>
> Some developers have chosen to use git as their distribution mechanism :-)
>
> That's fine but it does make the package download a tricky step, if you wish
> to have it automated. How about a git url and commit version put together?
>
> ie. I'm suggesting a download function like:
>
> $ git clone https://github.com/fgeorgatos/easybuild.git
> $ cd easybuild
> $ git checkout f43c755
>
> That should eventually build the following modulefile: EasyBuild/f43c755
>
> The idea is quite expandable, because it allows to be generalized with
> tags, branches etc, whatever git provides for. I have a use-case of RAxML.
>
Yep, I have this on my wish list as well, also for svn and bzr.
I hope this to will be added in the next month.
>
>
> OK, that's it, I stop it for today :-)
>
> cheerio,
>
> Fotis
>
>
>
> (1)
> There is more discussion to be done here as regards python namespaces but,
> fact is we need to check options ourselves, to make any good recommendations:
>
> http://bytebaker.com/2008/07/30/python-namespaces/
>
