> On Feb 25, 2015, at 3:12 AM, Cody Goodman <codygman.consult...@gmail.com> > wrote: > > Using cabbage you only need to do 'cabbage; nix shell'. iirc, the sandboxes > were transparent. > This is correct. Linking into the local sandbox is a separate, optional step. I wanted this as it let me continue using my old pre-nix workflow. However, fully supporting a workflow based entirely on nix-shell is not yet done as I was content to let cabal pass GHC all the necessary inputs based on sandbox contents. The missing piece for a nix-shell workflow is to duplicate that command line generation logic. What cabbage buys you is that you're starting with derivations whose dependencies are pinned to specific versions and flag settings. This lets you drop multiple instances of the same version of a package in your store for re-use in subsequent builds (this is all spelled out in more detail in the cabbage documentation). For nix-shell, you could save off an environment variable that just lists off the compiled libraries in the store for every derivation in the .cabbages directory. This would amount to a tweak of the existing generation of commands that link those libraries into the local sandbox. Anthony >> On Feb 24, 2015 11:57 PM, "Mateusz Kowalczyk" <fuuze...@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 >> > <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 > _______________________________________________ > 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
