Hi, Thanks. That was a lot to read and understand. I think my favourite solution would be Shea's recursive-derivations branch.
Without that we're trying two different ways for keeping our dependencies in the external repository: 1) Create a build.nix and use a custom builder instead of e.g. buildPythonPackage. 2) Have a custom "import" builder which unpacks a source and throws away everything other than .nix files. We can then import from that custom builder (basically [1]). Not sure which one we'll keep long term. ~ [1] https://gist.github.com/teh/ad22d636e7cb3c4d89ee On 18 March 2015 at 16:11, Shea Levy <[email protected]> wrote: > See https://github.com/NixOS/nix/pull/213. The comment chain is long, but > it’s important to read up to > https://github.com/NixOS/nix/pull/213#issuecomment-43674771. > > ~Shea > > On Mar 18, 2015, at 12:02 PM, Thomas Hunger <[email protected]> wrote: > > Apologies, here's the rest of my email: > > .. but I could not find anything that looks like "evaluate at build time" > - is that code somewhere public? > > Thanks, > Tom > > [1] > https://github.com/shlevy/nix > > > On 18 March 2015 at 16:01, Thomas Hunger <[email protected]> wrote: > >> Hi Shea, >> >> I checked your github version of nix [1] >> >> >> [1] >> >> >> On 18 March 2015 at 14:39, Shea Levy <[email protected]> wrote: >> >>> You can already do this. “import foo” will build any derivations that >>> “foo” depends on at evaluation time. >>> >>> Note though that really “build at evaluation time” is for several >>> reasons inferior to “evaluate at build time”, i.e. recursive nix. I have an >>> implementation for that but it doesn’t look like it will be accepted. >>> >>> ~Shea >>> >>> On Mar 18, 2015, at 8:36 AM, Kirill Elagin <[email protected]> wrote: >>> >>> I’d say there is a more general problem. >>> >>> Imagine, that one day [in a far far away future] people start shipping >>> derivations in `default.nix` in their sources (I guess people who develop >>> on NixOS/with nixpkgs already do this as they have the file for their build >>> environment anyway, so why not commit it). And then we have two copies of >>> derivations: in the source repository and in `nixpkgs`. >>> >>> So it really looks like having something like `fetchDerivation("…url…")` >>> would be handy. This function should fetch the source, unpack it, extract >>> `default.nix` and use it as derivation to build the already fetched source. >>> This way the `nixpkgs` repository itself is not required for packages that >>> have this kind of information shipped and other projects can depend >>> directly on the urls of repos. Then nixpkgs could be thought as a database >>> of “well-known” packages with their urls. >>> >>> On Wed, Mar 18, 2015 at 2:53 PM Luca Bruno <[email protected]> >>> wrote: >>> >>>> On 18/03/2015 12:37, Thomas Hunger wrote: >>>> > Thanks. >>>> > >>>> > That would require having the shell.nix library locally already >>>> > AFAICT. To rephrase slightly. Ideally I'd like to be able to do: >>>> > >>>> > myLibrary = fetchurl { ... }; >>>> > extraDepends = import "${myLibrary}/depends.nix"; >>>> > buildDepends = [ ... ] ++ extraDepends; >>>> > >>>> > Does that make sense? >>>> I understand that, but I think the best fit of nix usage is having all >>>> the nix expressions in the same repository, instead of spreading nix >>>> files on every repository. That is, what's nixpkgs is doing. >>>> >>>> So I would create a repo of all nix files, which fetch sources from your >>>> other repos. >>>> _______________________________________________ >>>> 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 >>> >>> >>> >> > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
