Is your feature request related to a problem? Please describe.
At ILM, we have a distinct workflow where many packages are maintained from a single repo (not currently spk). Our developer and CI workflows operate on "collections" that construct a simple dependency DAG and then build packages that don't exist in order. Notably, the package recipes work for all possible versions of the package and so the version is provided by the collection, not the package spec.
Describe the solution you'd like
We would like to convert these packages into spk packages and then have a way to orchestrate builds in the same way using spk.
Describe alternatives you've considered
We could hook spk into our existing system, eg build the DAG ourselves and then invoke spk, but resolving the dependencies properly in such a DAG is difficult due to spk spec files being difficult to introspect from the outside, especially as a set of var options are included in the picture.
related to #1120 in that we could possibly do this with more useful introspection of spk recipes
also related to other issues orchestrating variant builds in CI and properly determining what needs to be done
we kind of have this if we do build from source with published packages, though there is no great way to interpret the output of spk explain
this can't handle versions, so we could instead inject the version in order to create the source packages and then run spk
this is also related to the package specs and build process that we have in the spk repo itself. This is a good first use case for related functionality - having it be able to build the tree on its own without Make.
Is your feature request related to a problem? Please describe.
At ILM, we have a distinct workflow where many packages are maintained from a single repo (not currently spk). Our developer and CI workflows operate on "collections" that construct a simple dependency DAG and then build packages that don't exist in order. Notably, the package recipes work for all possible versions of the package and so the version is provided by the collection, not the package spec.
Describe the solution you'd like
We would like to convert these packages into spk packages and then have a way to orchestrate builds in the same way using spk.
Describe alternatives you've considered
We could hook spk into our existing system, eg build the DAG ourselves and then invoke spk, but resolving the dependencies properly in such a DAG is difficult due to spk spec files being difficult to introspect from the outside, especially as a set of var options are included in the picture.