Re: [Nix-dev] haskell: overriding mtl/any builtin
There is no problem overriding `mtl` with a newer version than the one GHC provides assuming we also override all packages depending on mtl. I think this is possible as long as the package using mtl doesn't depend on the GHC api (ghc package), because we cannot override the GHC api package and it depends on mtl. -- Benno 2014-09-08 17:50 GMT+02:00 Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk: On 09/08/2014 07:36 AM, Peter Simons wrote: Hi Mateusz, Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 transformers is a core library in GHC 7.8.3. We cannot override that package, because it's shipped with the compiler and other core libraries are linked against that version. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Right, yes, it is, yet somehow there are packages around on Hackage which do depend on mtl-2.2.1 and by proxy on transformers-0.4, which do compile with GHC 7.8.3. This must be somehow achieved one way or another and currently with nix(pkgs) we can not accommodate for those packages. Recent release of JuicyPixels is a good example, we had to ask upstream to relax the bound a bit so that we could use it but just relaxing the bound is not always possible. I expect more and more packages to start using the new mtl over time. I found myself yesterday in need of hacking a bit on a project which happened to actually need mtl-2.2.1 and I just could not do it with 7.8.3 whereas that's exactly what the original developer was using. My hack there was to comment out the 2.2.1 imports and manually stick undefined everywhere but that's obviously not acceptable for any actual work. The only other way I could think of would be to use the (outdated) GHC ‘HEAD’ version from nixpkgs which would not help me because it was to try and chase down a bug appearing with 7.8.3. -- 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
Re: [Nix-dev] haskell: overriding mtl/any builtin
Hi Mateusz, Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 transformers is a core library in GHC 7.8.3. We cannot override that package, because it's shipped with the compiler and other core libraries are linked against that version. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
On 09/08/2014 07:36 AM, Peter Simons wrote: Hi Mateusz, Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 transformers is a core library in GHC 7.8.3. We cannot override that package, because it's shipped with the compiler and other core libraries are linked against that version. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Right, yes, it is, yet somehow there are packages around on Hackage which do depend on mtl-2.2.1 and by proxy on transformers-0.4, which do compile with GHC 7.8.3. This must be somehow achieved one way or another and currently with nix(pkgs) we can not accommodate for those packages. Recent release of JuicyPixels is a good example, we had to ask upstream to relax the bound a bit so that we could use it but just relaxing the bound is not always possible. I expect more and more packages to start using the new mtl over time. I found myself yesterday in need of hacking a bit on a project which happened to actually need mtl-2.2.1 and I just could not do it with 7.8.3 whereas that's exactly what the original developer was using. My hack there was to comment out the 2.2.1 imports and manually stick undefined everywhere but that's obviously not acceptable for any actual work. The only other way I could think of would be to use the (outdated) GHC ‘HEAD’ version from nixpkgs which would not help me because it was to try and chase down a bug appearing with 7.8.3. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
mtl choosing versions Which is the target package you want to use/work on? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
On 09/07/2014 10:57 AM, Mateusz Kowalczyk wrote: On 09/07/2014 10:15 AM, Marc Weber wrote: mtl choosing versions Which is the target package you want to use/work on? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev In this case =mtl-2.2.1 but I'd like to know the solution in general. As long as we could ‘cabal install whatever’ on a regular distro, I'd like to know how to achieve the same thing with nix. Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] haskell: overriding mtl/any builtin
Hi, GHC ships with a bunch of libraries that are exposed. How can we override those so that the compilation still succeeds and we don't end up with two versions in scope? A sample use-case is using things which depend on ‘mtl’ 2.1.2. Usually I try to work with upstream to make the bound more flexible but this is suboptimal. In this case the problem is with the Haskell ‘cgi’ package which needs mtl 2.2.1: they had fixed up some failures for 7.8.3 so that it could compile but we fail at the configure stage. Normally a user would just cabal-install mtl so how do we adapt? Assume jailbreak doesn't work. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
