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 > <fuuze...@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@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@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Mateusz K. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev