Using cabbage you only need to do 'cabbage; nix shell'. iirc, the sandboxes were transparent. On Feb 24, 2015 11:57 PM, "Mateusz Kowalczyk" <[email protected]> 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 > > <[email protected]> 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 > >>> [email protected] > >>> 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 > >> [email protected] > >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > > _______________________________________________ > > nix-dev mailing list > > [email protected] > > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > > -- > Mateusz K. > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
