Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?
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 s...@shealevy.com 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 tehun...@gmail.com 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 tehun...@gmail.com wrote:
Hi Shea,
I checked your github version of nix [1]
[1]
On 18 March 2015 at 14:39, Shea Levy s...@shealevy.com 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 kirela...@gmail.com 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 lethalma...@gmail.com
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
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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?
On 18/03/2015 11:26, Thomas Hunger wrote:
Hi,
I usually include a shell.nix file in my libraries for development. If
I have a dependency not in core nixpkgs then I add a local
mkDerivation using let pkg = ... in {} to shell.nix (e.g. [1]).
If I now want to use my library in another context, say nixops, I have
to duplicate the shell.nix content because I cannot import from a
project I'm depending on.
I considered having a separate repository of nix expressions that is
used for shell.nix as well as nixops but that makes it hard to release
a standalone libraries on github.
Then make nixops import stuff from your shell.nix ?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Question about organising dependencies not in core nixpkgs?
Hi,
I usually include a shell.nix file in my libraries for development. If I
have a dependency not in core nixpkgs then I add a local mkDerivation using
let pkg = ... in {} to shell.nix (e.g. [1]).
If I now want to use my library in another context, say nixops, I have to
duplicate the shell.nix content because I cannot import from a project I'm
depending on.
I considered having a separate repository of nix expressions that is used
for shell.nix as well as nixops but that makes it hard to release a
standalone libraries on github.
Is this a problem other people experience? If so: how do you solve this?
Thanks best,
Tom
[1]
let
flask-oidc = pythonPackages.buildPythonPackage rec {
name = flask-oidc-0.1.2;
[...]
};
in
buildPythonPackage { ... }
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?
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
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?
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 lethalma...@gmail.com 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
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] Question about organising dependencies not in core nixpkgs?
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?
~
On 18 March 2015 at 10:31, Luca Bruno lethalma...@gmail.com wrote:
On 18/03/2015 11:26, Thomas Hunger wrote:
Hi,
I usually include a shell.nix file in my libraries for development. If
I have a dependency not in core nixpkgs then I add a local
mkDerivation using let pkg = ... in {} to shell.nix (e.g. [1]).
If I now want to use my library in another context, say nixops, I have
to duplicate the shell.nix content because I cannot import from a
project I'm depending on.
I considered having a separate repository of nix expressions that is
used for shell.nix as well as nixops but that makes it hard to release
a standalone libraries on github.
Then make nixops import stuff from your shell.nix ?
___
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] Question about organising dependencies not in core nixpkgs?
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 kirela...@gmail.com 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 lethalma...@gmail.com
mailto:lethalma...@gmail.com 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
nix-dev@lists.science.uu.nl mailto:nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?
Hi Shea,
I checked your github version of nix [1]
[1]
On 18 March 2015 at 14:39, Shea Levy s...@shealevy.com 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 kirela...@gmail.com 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 lethalma...@gmail.com 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
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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?
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 tehun...@gmail.com wrote:
Hi Shea,
I checked your github version of nix [1]
[1]
On 18 March 2015 at 14:39, Shea Levy s...@shealevy.com 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 kirela...@gmail.com 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 lethalma...@gmail.com 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
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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
