add modular support for handling non-easyconfig files

[boegel]

We could implement support to handle on-.eb files in a modular way. e.g., .rpm, .srpm, .spec, .deb, .py, etc.

That way, someone else can write a function/class for handling e.g. .spec files or source RPMs.

Related: see rpm Python module: https://bugzilla.redhat.com/show_bug.cgi?id=662119#c3).

[fgeorgatos]

On Wed, Aug 29, 2012 at 5:15 PM, Kenneth Hoste notifications@github.comwrote:

We could implement support to handle on-.eb files in a modular way. e.g., .rpm, .srpm, .spec, .deb, .py, etc.

That way, someone else can write a function/class for handling e.g. .spec files or source RPMs.

Related: see rpm Python module: https://bugzilla.redhat.com/show_bug.cgi?id=662119#c3).

Recommendation: let "external" handlers manage anything non default, people should scratch their own itches... http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar#Guidelines_for_creating_good_open_source_software

(this can go as far as, .spec files calling "Open Build Service" to produce relocatable rpms, then deploy them; if there is enough orthogonality, only imagination can limit how many features can be built via this mechanism...).

[boegel]

The "modular" part in the issue title is intended exactly for allowing to plug in handlers for formats we don't know about. It should be simple to allow people to supply .foo to EasyBuild, which then makes EasyBuild try and use the FooFile class to try and make sense of it. If there's no FooFile available, then it will fail.

That way, simply adding handlers for e.g. .foo to the PYTHONPATH is sufficient.

We may have to restrict the class name a bit more to avoid surprises, but this seems like a general approach that would work well for allowing support for custom compilers, MPI libraries, math libraries, etc.

[fgeorgatos]

Hi there,

coming back to this open issue:

• Could we perhaps be able to call a wrapper script, like: handle_suffix_foo.sh, spitting an easyconfig on stdout, so that we can solve it quickly? I think these wrappers should not be confined to being in Python only (partly because it allows for code reuse across projects handling packages)

Then, you would be able for example, to go here and search for lua, http://layers.openembedded.org/layerindex/recipes/ then, pick the .bb file and attempt a conversion to easyconfig: http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-core/coreutils/coreutils_8.21.bb?h=master Even if the build fails and it is incomplete, you save time be getting a decent template.

See another example where the chance of success would be even higher: http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-core/coreutils/coreutils_8.21.bb?h=master btw. notice how certain builddependencies are visible under *_LINK_NAME?

btw. let's expect the individual wrappers to be written by folks like me; what we miss is in-framework support here.