@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
