-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the concept of .ebp patch file or similar, for local site modifications #544
Comments
To be more clear: this is intended to support easyconfig-specific customizations easily. When EasyBuild finds a |
what do you want to save in the local repo? both files, or the result sfer patching? |
The result, imho, since it's a local repo. When we add the feature to automagically start pushing easyconfigs that worked upstream, that's another issue... |
I can see 3 levels of patches:
(1) allows also for (2) and has the advantage that you don't miss the upgrades/bugfixes from upstream, so easily. My gut feeling says that the above is generic enough to cover plenty of needs, but time will tell us what's right! |
Having this in place would also allow to scratch the ignoring of CPU throttling in the ATLAS easyconfigs we ship, and simply use |
fyi. this is extracted as-is from the customization of MPI stacks and TotalView on this end, to prove the issue:
|
@fgeorgatos: Thanks for sharing this, this will help us in figuring out how to properly support site customizations. |
@jas02: you may be interested in this idea/concept w.r.t. managing site customisations of easyconfigs |
discussed this a bit now: it would be a conditional step of retrieving an .ebp file and, On 28 January 2016 at 11:18, Kenneth Hoste [email protected] wrote:
|
btw. the other viable alternative is to maintain your diffs in a git branch
On 28 January 2016 at 14:02, Fotis Georgatos wrote:
|
as mentioned by @besserox during today's EB conf call: maybe there's no need for this at all, since maintaining patches on top of the mainline easyconfigs in separate branch in a clone of the |
The concept of .ebp does indeed look interesting and i can immediately see lots of uses for it. What's the status? |
I think this was in stalled state until today ;) Basically, people got convenienced with git commits and workflows, so this On Friday, October 21, 2016, Åke Sandgren [email protected] wrote:
|
Indeed, it got stuck to being just an idea... Even though people have resorted to git instead, I could still see this being useful though. @akesandgren up for giving it a try? I could give you some pointers... |
Not at the moment, way to much things to deal with first... |
Doesn't adding support for Easyconfig patch files come down to something like "amend from file"? EasyBuild would have to look for a file with the same name as the easyconfig but with an '.ebp' extension and parse it after the real easyconfig. In the 'ebp' file one would be able to use What do you think? |
@geimer There may be a use case for storing the |
So, as regards the pythonic version of easyconfigs, the --amend-from-file
approach may well make sense;
since it allows more fine manipulation of existing settings, including
using conditionals (which could be thought as evil by some).
My take is, that it might not be the final answer, yet it appears
reasonable for the near future!
F.
…On Sat, 11 Feb 2017 at 17:24, geimer ***@***.***> wrote:
Doesn't adding support for Easyconfig patch files come down to something
like "amend from file"?
EasyBuild would have to look for a file with the same name as the
easyconfig but with an '.ebp' extension and parse it after the real
easyconfig. In the 'ebp' file one would be able to use = to overwrite
values and += to extend them. The stored easyconfig would then simply be
the concatenation of the two (just like an easyconfig used with
--try-amend). These "amend files" would IMHO be much easier to maintain
than real patch files in case of changes in the upstream easyconfig.
What do you think?
|
This discussion is moving in the direction of what we are already discussing (and @rjeschmi
We could consider an additional |
I have committed some of the test cases and very rough functions into a branch here: https://github.com/rjeschmi/easybuild-framework/tree/fat-yaml |
This in effect will allow to store patchfiles at local HPC sites as opposed to complete easyconfigs, which has the important advantage of allowing to benefit from upstream updates & bugfixes (think of MPI stacks that require local tuning, about this).
I think the following will help understand the use-case:
It is important to support this in the framework, to allow automated pick-up of such diffs during robotic builds with dependencies etc.
The text was updated successfully, but these errors were encountered: