Request for feedback on spec/proposal for distributing package collections via hackage

[Gershom B]

> 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 <ezyang at mit.edu> wrote:
> 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-control
> 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
>