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

[Mateusz Kowalczyk]

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.