and is there any point to having a collection without versions in it? (If Cabal syntax is extended to support depending on collections as well as packages, yes?)
So I think another use-case for collections, besides "version-locked",
is sets of "blessed" packages. So we might want a collection for
"verified compatible with windows 2008" or "platform packages" or
"works with nhc" to be collections.
And in those cases, specifying unique versions doesn't seem to make
much sense. And one could imagine taking intersections -- i.e.
"uhc-compatible _and_ in stackage LTS".
In general I like this proposal as very minimal in terms of just
providing and collecting data, and allowing that data to then be used
by clients in various ways.
--gershom
On Tue, Jul 14, 2015 at 3:02 PM, Edward Z. Yang
Hello Duncan,
In my eyes, this proposal looks like some sort of generalization of Stackage; and one further use case is "special purpose" collection. My big question: how composable are these collections really? I can't put two collections with conflicting versions together (or can I? Do I union?); and is there any point to having a collection without versions in it? (If Cabal syntax is extended to support depending on collections as well as packages, yes?)
The classic use-case for package collections is deployment settings, ala Stack, or even Cargo lockfiles / Bundler Gemfile.lock (versioned collections). In all these use-cases package collections are treated as non-compositional things. http://doc.crates.io/guide.html http://bundler.io/v1.7/rationale.html#checking-your-code-into-version-contro... Libraries (compositional) do NOT publish lockfiles: only executables (non-compositional) DO.
Re the file format, it seems fine; suitable for the lockfile use-case and the Stackage use-case. Less sure about the unioning semantics.
Edward