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. Best regards, Mikael On Thu, Dec 27, 2018 at 12:06 PM Mikael Öhman <[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 > >
