[Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?

Cody Goodman codygman.consulting at gmail.com
Wed Feb 25 09:12:32 CET 2015


Using cabbage you only need to do 'cabbage; nix shell'. iirc, the sandboxes
were transparent.
On Feb 24, 2015 11:57 PM, "Mateusz Kowalczyk" <fuuzetsu at fuuzetsu.co.uk>
wrote:

> On 02/25/2015 03:01 AM, Anthony Cowley wrote:
> > This almost certainly isn't ready for release, but I'd like to avoid
> > duplicating efforts if other people want to work on it...
> >
> > Here is cabbage https://github.com/acowley/cabbage
> >
> > It is a tool for doing the obvious thing: use the cabal solver to find
> > a build plan, then build the specific version of each package, and
> > then link them into the sandbox in the current directory.
> >
> > As I said, this script has every warning tape and flashing light
> > imaginable attached to it. I've used it to install ghc-mod, pandoc,
> > hakyll, a bunch of web things like amazonka, and my Frames package
> > with all its demos (involving Chart, diagrams, JuicyPixels, and who
> > knows what else).
> >
> > There are missing pieces outlined in the Tasks list at the end of the
> > Org file that is the source code for the script. I would more than
> > welcome contributions as this is how I would like to use Nix with
> > Cabal, and getting help from like-minded folks would be a big boost!
> >
> > Anthony
>
> While interesting, I feel it is doing too much and using the wrong
> tooling at least for me. I have the power of nix-shell, I don't want to
> be using ‘cabal sandbox’ on top of it, that very much goes against all
> the benefits of using nix-shell to begin with. I don't call ‘cabal’
> manually pretty much ever unless it's ‘cabal update’ though I know of
> cases where you still might prefer cabal repl over ghci, something I
> hopefully won't have to deal with.
>
> I think a simpler solution from the user experience perspective is if we
> can do something like ‘hackage2nix myproject.cabal’ which runs through
> the cabal solver and then spits out hackage-packages.nix with only the
> stuff that is needed with versions that are needed. We can now happily
> use this package set in our shell.nix or whatever just like we do today
> with manually written package sets. If it can do that then everything
> else works just like it does today already which is a good thing ;). If
> I want to do this today then I nix-build a package, see what version in
> complains about, add the package to the project's set and repeat until
> physically ill.
>
> >
> > On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk
> > <fuuzetsu at fuuzetsu.co.uk> wrote:
> >> On 02/22/2015 12:04 PM, Peter Simons wrote:
> >>> Hi Cody,
> >>>
> >>>  > haskellngPackages doesn't seem to have all versions of all
> dependencies...
> >>>
> >>> I'm not sure what you mean by "all versions of all dependencies".
> Dependencies
> >>> of what exactly? The way I understand the term, "dependency" has
> meaning only
> >>> as a relationship between two packages, i.e. "transformers" is a
> dependency of
> >>> "mtl". I'm not sure how to apply that interpretation to your question?
> >>>
> >>> If you're asking why hackage-packages.nix doesn't contain every single
> version
> >>> of every package registered on Hackage, then the answer is because
> that would
> >>> be a database containing well over 50,000 packages, the vast majority
> of which
> >>> no-one will ever care about (nor will they ever compile). So it seems
> pointless
> >>> to distribute all that stuff as part of Nixpkgs.
> >>>
> >>> Best regards,
> >>> Peter
> >>>
> >>> _______________________________________________
> >>> nix-dev mailing list
> >>> nix-dev at lists.science.uu.nl
> >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>>
> >>
> >> A related question: is there a way to generate a package list containing
> >> exactly the versions of dependencies we require?
> >>
> >> Say we have a package with cabal file
> >>
> >> A == 1.0
> >> B > 2.0
> >> C < 0.5
> >>
> >> but the latest Hackage has versions lower and higher &c and that's what
> >> is in nixpkgs. I found myself wishing that there was an easy to just say
> >> ‘give me a set of packages that's valid from cabal's point of view’
> >> rather than what we currently tend to do which is ‘include latest
> >> versions of everything, jailbreak and hope it works’ which is fine for
> >> nixpkgs but subpar if we just want that one project working but it
> >> requires specific versions of dependencies.
> >>
> >> --
> >> Mateusz K.
> >> _______________________________________________
> >> nix-dev mailing list
> >> nix-dev at lists.science.uu.nl
> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> > _______________________________________________
> > nix-dev mailing list
> > nix-dev at lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
>
>
> --
> Mateusz K.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150225/5bec5cbb/attachment.html 


More information about the nix-dev mailing list