Coder Social home page Coder Social logo

Comments (4)

sternenseemann avatar sternenseemann commented on July 17, 2024 1

Your solution is correct. Because cabal2nix can only output a bunch of names without deciding how to resolve them, it can't really deal with the problem – you need to do so manually when calling the generated expression.

let
  pkgs = import <nixpkgs> {};
in

haskellPackages.callPackage ./generated-by-cabal2nix.nix {
  inherit (pkgs) flac;
}

(When generating hackage-packages.nix in nixpkgs, hackage2nix can actually do this automatically, so your fix would benefit the package expression in nixkpgs.)

from cabal2nix.

sternenseemann avatar sternenseemann commented on July 17, 2024 1

You are right callPackage already passes in a pkgs variable, so we could do exactly that. The primary reason this is not done is overriding. If we use pkgs.flac in the derivation then you can‘t pass in another version of the flac the C library via overrides.

It's not just that, it is also fundamental to the design to nixpkgs that packages are passed individually via callPackage and important implementation details rely on this, e.g. cross-compilation relies on this.

from cabal2nix.

414owen avatar 414owen commented on July 17, 2024

Interesting. A few thoughts:

  1. Is there currently no way to depend on nixpkgs.x and also haskellPackages.x?
  2. cabal2nix --shell also creates a recursive derivation here, even though both pkgs and haskellPackages.* are in scope. This should be fixable, right?
  3. Is there a reason we can't generate something like: { mkDerivation, base, pkgs }:, where pkgs is a reference to nixpkgs proper, this would avoid confusion (not knowing which package you're looking at), and support dependencies on both versions of a package

from cabal2nix.

maralorn avatar maralorn commented on July 17, 2024

Those are good questions and you are not the first person to be annoyed by this design.

  1. Not trivially. Usual workaround is to rename one dependency locally or do 3. I don‘t think cabal2nix can do any of that automatically, but I don‘t know.
  2. You are right callPackage already passes in a pkgs variable, so we could do exactly that. The primary reason this is not done is overriding. If we use pkgs.flac in the derivation then you can‘t pass in another version of the flac the C library via overrides.

from cabal2nix.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.