Dear Mikael,
On 13/01/2019 18:26, Mikael Öhman wrote:
Hi all,
I told Kenneth that I would try to summarize alternatives;
https://gist.github.com/Micket/68153b209e29fc44bf0b85c7414e197d
I hope I haven't misrepresented anyones suggestion
This is a very nice summary, thanks a lot for puzzling this together!
Why not create a dedicated issue for this via
https://github.com/easybuilders/easybuild-easyconfigs/issues, so we can
follow up on it in context and easily refer to it later?
Other relevant easyconfig PRs you can mention include:
* https://github.com/easybuilders/easybuild-easyconfigs/pull/4962 (which
was reverted in
https://github.com/easybuilders/easybuild-easyconfigs/pull/5075)
* https://github.com/easybuilders/easybuild-easyconfigs/pull/5072
I propose we continue the discussion on this in the next EasyBuild conf
call (planned for this Wednesday, Jan 23rd 2019 at 5pm CET)?
regards,
Kenneth
Best regards, Mikael
On Thu, Dec 27, 2018 at 12:06 PM Mikael Öhman <[email protected]
<mailto:[email protected]>> wrote:
@Paul Melis,
Good question. I'll admit I actually filter-deps Mesa itself (we use
the system Mesa to get VirtualGL working). I just see the follow up
effects, all the packages that in turn depend on Mesa (and a couple
other basic softwares with Python bindings)
@Alan,
I've also felt for some time that we could be splitting groups
of python packages off from the core Python installation (for
example, at JSC we already bundle all the SciPy packages), but
for this to be effective without causing lots of headaches it
would have to be done unilaterally. One could I suppose take the
approach of GCCcore/GCC (the actual compiler is in GCCcore, GCC
is a bundle that includes this as a dep), with `Pythoncore` (or
whatever) being a dependency of the bundle `Python` which
includes all the relevant packages. Such an approach would keep
the general structure we already have.
This is exactly what I did for 2018b; but, there are some unexpected
side-effects from this; the name "Python" is used by EB to determine
the %(pyver) value.
This issue is of course very easily fixable (even if it just turns
into hard-coding a alternative name), but I think the other approach
is a bit cleaner.
-----
I will make extra effort to attend the next user meeting, though I
probably have already mentioned everything I think about this.
I don't think the change is (or at least needs to be) as drastic as
it's made out to be. One module gets split into 2, and then there is
just moving what can to GCCcore, which is something that has already
been done to many other modules. Basically only benefits.
Happy holidays!
/ Mikael
