@tgamblin @becker33 Keywords: variant forwarding, Spack Environments

This thread is a continuation of discussion in #3049. The key idea is we (software authors) need to think of our projects as a software DAG with a root combined with some project configuration info, rather than our top-level project plus dependencies. There is nothing special about the root of my DAG --- especially if someone else uses my top-level application as a libarary.

However, I think this is a compelling case for using forwarding. The semantics of it make sense -- lbann with debugging is useless when elemental does not have debug symbols.

I don't think that's compelling because it's way too common. There are plenty of other base numerical packages like Elemental, where it makes sense to enable/disable debugging on them and the applications that rely on them simultaneously. PETSc, Eigen, METIS, SuiteSparse, just to name a few... Altogether they have at least dozens of applications from which one could imagine forwarding the +debug variant.

We need to think of a way to address this issue at the Spack level, rather than the per-package level. Once that is done, we will have to rip out all the variant forwarding the package level. There is no way to grep for variant forwarding, although we can (and will need to) grep for debug.

This package isn't widely used

I think that is the most compelling argument to allow the variant forwarding in this case.

on similar grounds to our decision in #2670

I think that #2670 is more problematic than this #3049. #2670 contains a lot of ~ characters in its depends_on() directives. These are known to break the concretizer, and I'm not sure a new concretizer will fix that; witness the ongoing problems people have building R, in the light of things like depends_on('pango~X'). I suppose the similarity is that in both cases, users did not want to use the packages.yaml functionality --- and it is expedient to allow that for rarely-used packages.

It seems we keep running into cases where people want to code site-specific or project-specific stuff into packages. And then we have to choose between convenience of those users vs. flexibility (for other users) of the package that is ultimately created. Here is what I think we can learn from this experience:

Takeaway Points

1. What do we need to change to make things both convenient and flexible for users? I believe we need to encourage thinking of projects as a DAG of software, rather than single package. And put explicit support for it in Spack, and discussion in the manual. Even if you are the author of the top-level package in a DAG, we should encourage you to think of the project as being a collection of pacakges, rather than "your single package plus dependencies." And remember... the top-level package in your project's DAG could end up as not-the-top-level in someone else's DAG. Right now, Spack has now support for anything beyond packages; so people keep defaulting to the top-level package as their project. Hence the desire to forward dependencies from it.

I believe/hope that Spack Environments can go a long way to addressing this issue. We should keep it in mind as we design Spack Environments further.

2. Beyond that, the fundamental trade-off with Spack seems to be that you save time by not writing all the packages yourself --- but you have to spend more time (a) making your packages useful to others, at least if they're packages that others will want to use, and (b) chasing down problems introduced when others change packages, sometimes just with version upgrades. I believe the trade-off is worth it. But we could do better making this trade-off explicit in our docs (discussion sections), building best practices on package authorship.

3. I also believe we could do better, as a community, on developing shared practices on package writing. It turns out to be a lot more complicated than just reading the Packaging Guide. The fundamental assumption that needs to be jettisoned with Spack is the assumption that your package is the top of the DAG. I believe we should always work under the assumption that somebody else might come along and use our top-level package that we worked so hard on as a dependency for their even-higher-level package.

I would really like to address making variants more sane after we get the concretizer done.

Do you have specific ideas on what ideas or mechanisms for saner variants might be enabled by the new concretizer? I believe the biggest outstanding problem is forwarding through virtual packages --- and that's not an issue here.

I have some variant upgrades we've discussed in the Issues... as soon as #2386 is merged, I want to start working on them.