[Nix-dev] cabal-install 1.24's Nix-style builds, and a new style of Nix + language package manager integration

[John Ericson]

Hi Peter,

Thanks for trying and sorry I haven't been able to articulate this
well. You left a similar comment about the same time, and I responded
in https://github.com/haskell/cabal/issues/3882#issuecomment-249312464,
but for the benefit of this list I will recap and expand here.

The primary purpose of my plan is to make our Haskell infrastructure
smaller and simpler by leveraging cabal-install, *not* to add more
features. A lot of work goes into cabal2nix, and I think we can get
the same functionality with less of a maintenance burden. I want to
make it so there is as little overlap as possible between our Haskell
infrastructure (especially cabal2nix) and cabal-install. [Finally,
there's no reason we couldn't do the same with Stack; I am starting
with cabal-install because I think it's new features make working with
it easier.]

Now, one concrete problem I did mention in the first post of this
thread is working with packages that have compiler-specific metadata,
like GHCJS-specific dependencies. But that has actually been recently
fixed with https://github.com/NixOS/cabal2nix/pull/230, and is thus
*not* an example of something that can *only* be solved with my plan.
But it does serve an example of the type of maintenance work I'd like
to obviate: I only see more complications to evaluating cabal files
like "impl(ghcjs)" appearing in the future, and it would be nice to
avoid cabal2nix always playing catch-up, implementing them after
Cabal.

If we can put my basic proposal in place, there is follow up work that
will yield actual new features, such as nicer local development of
multiple packages that is more similar to (the good parts of) non-Nix
workflows, working with LTSes again or other upstream package sets
without bloating nixpkgs, and more. But this stuff is a bit more
experimental and I rather "sell" my idea on the just the benefit of
less maintenance and complexity alone.

Hope that helps,

John

On Fri, Sep 23, 2016 at 1:19 PM, Peter Simons <simons at nospf.cryp.to> wrote:
> Hi John,
>
> I have really tried my best to understand what exactly it is you are
> suggesting in this thread and why that suggestion might be desirable,
> but I haven't been able to grok your proposal.
>
> Would it be possible to explain your thoughts using a *concrete*
> example, i.e. could you maybe give us a *specific* example of a use-case
> that does not work today, but that would work correctly if your proposal
> were implemented?
>
> Best regards,
> Peter
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev