Decide on syntax for compiler virtual dependencies

[rgommers]

We figured out virtual dependencies with a fixed name, like openmp or blas. But for compilers we didn't figure it out yet. Options:

• "virtual:compiler{'rust'}" ~(this is in the draft right now)~ changed to virtual:compiler/c now
• "virtual:compiler-rust" (use separate names)
• ... ?

@pradyunsg WDYT?

[rgommers]

Comment by @jaimergp:

virtual packages use PURL too right? So what about virtual:compiler/c. Some tools might want Clang specifically, with a certain version (even if we are not providing this info yet in the absence of PURL version ranges).

No, as it stands virtual: isn't using PURL; PURLs exclusively start with pkg:. If we're separating compiler and c, then compiler looks like a "type" in:

scheme:type/namespace/name

Maybe there's something to that, we have these components:

• scheme: pkg or virtual
• type: pypi, cargo, github, generic, etc. for PURL. The compiler "virtual type" for our virtual.
• name: numpy, ripgrep, openblas, etc. package names for PURL. c, cpp, rust, etc. for our compiler virtual type

So then the logical follow-up would be: we need only well-defined virtual "types". I can only think of two: compiler and interface. The latter would be openmp, mpi, blas, lapack. I also had virtual:ssl, but that is actually wrong - while SSL is a protocol, it doesn't have a standard API/interface. cryptography supports multiple SSL libraries, but they're all forks of OpenSSL. So that example should simply use pkg:generic/openssl.

What can't really be expressed is "I need one of these three alternatives for function X". That doesn't fit in either pkg or virtual really, unless there's a syntax for expression OR or fallback.

[jaimergp]

Alternatively, how difficult would it be to convince the PURL authors to include a new type for these abstract requirements? Maybe generic subtypes? Or a new one such as abstract? E.g.:

• A C compiler would be pkg:abstract/compiler/c. A concrete one would be pkg:generic/gcc.
• A BLAS implementation would be pkg:abstract/interface/blas. A concrete one would be pkg:generic/openblas.

[rgommers]

Alternatively, how difficult would it be to convince the PURL authors to include a new type for these abstract requirements?

Yep, I had already opened gh-5 as an action for myself to do exactly this later today. That would be ideal I think.

[rgommers]

Done in https://github.com/package-url/purl-spec/issues/222

[rgommers]

Also under Open Issues in the draft PEP, and no response on the purl-spec issue so far. PURL seems solid, but not well-maintained unfortunately.

[pradyunsg]

@pradyunsg WDYT?

I don't have enough understanding of the approaches we might have to take to resolve these virtual requirements to have a strong opinion formed on this. 😅

My personal plan is to discuss the upcoming improvements that Spack is going to be making around compilers, and to survey the way Conda (and maybe Fedora/Debian) are doing things to get a sense of what concretised variants of this would look like. Alternatively, we can expect those folks to engage during the PEP discussion (as they have) and help figuring out the answers to these questions.

[pradyunsg]

Honestly, as long as each "kind" of compiler maps to something unique, I'd be OK with whatever choice we make here. The current compiler/{lang} works well-enough IMO.

[rgommers]

Sounds like a good plan!

I think we'll also get a a better sense of prototyping some of the name mapping stuff. It's a matter of finding time for it, since it's not exactly trivial to do.