On Fri, Jul 6, 2012 at 2:45 PM, Lluís Batlle i Rossell wrote:
> On Fri, Jul 06, 2012 at 02:25:25PM +0200, Mathijs Kwik wrote:
>> On Fri, Jul 6, 2012 at 2:12 PM, Marc Weber wrote:
>> > Excerpts from Mathijs Kwik's message of Fri Jul 06 11:53:28 +0200 2012:
>> >> packageOverrides = pkgs:
>> >>
On Fri, Jul 06, 2012 at 02:25:25PM +0200, Mathijs Kwik wrote:
> On Fri, Jul 6, 2012 at 2:12 PM, Marc Weber wrote:
> > Excerpts from Mathijs Kwik's message of Fri Jul 06 11:53:28 +0200 2012:
> >> packageOverrides = pkgs:
> >> { foo = "string";
> >> bar = pkgs.foo + " concatenation";
> >
On Fri, Jul 6, 2012 at 2:39 PM, Kirill Elagin wrote:
> But the ``__overrides`` will be empty in ``pkgsOrig``!
> Those new attributes are not... hmm... actually merged into the attrset,
> they still reside in this attribute and "pkgsOrig = pkgsFun pkgs {}"
> overwrites everything in __overrides wit
Yes, that does apply to this problem.
The documentation is quite clear indeed.
__overrides makes some imperative "update/replace" trick possible.
pkgs := pkgs // overrides
which leads to pkgs being "updated" so even attributes in the original
version of pkgs can see the changes by "overrides"
Th
But the ``__overrides`` will be empty in ``pkgsOrig``!
Those new attributes are not... hmm... actually merged into the attrset,
they still reside in this attribute and "pkgsOrig = pkgsFun pkgs {}"
overwrites everything in __overrides with an empty attrset effectively
removing all your overrides com
For posterity, here's that link again hard-coded to the latest commit affecting
eval.cc:
https://github.com/NixOS/nix/blob/f491ae97d472bfd6305a8f3e8c58fac1fdc443a4/src/libexpr/eval.cc#L525
On Jul 6, 2012, at 8:23 AM, Shea Levy wrote:
> Hi Mathijs,
>
> I've not fully read the thread, but just
On Fri, Jul 6, 2012 at 2:28 PM, Kirill Elagin wrote:
> 2012/7/6 Mathijs Kwik
>>
>> Yeah I saw those comments too, but I can't see how that would work.
>> Because the "original" (pkgsOrig) set is built by passing pkgs (the
>> final set) to pkgsFun.
>> In other words, the set references itself, whi
2012/7/6 Mathijs Kwik
> Yeah I saw those comments too, but I can't see how that would work.
> Because the "original" (pkgsOrig) set is built by passing pkgs (the
> final set) to pkgsFun.
> In other words, the set references itself, which is perfectly normal
> in a lazy setting.
> The notion of "
On Fri, Jul 6, 2012 at 2:12 PM, Marc Weber wrote:
> Excerpts from Mathijs Kwik's message of Fri Jul 06 11:53:28 +0200 2012:
>> packageOverrides = pkgs:
>> { foo = "string";
>> bar = pkgs.foo + " concatenation";
>> };
>
> solution a) use rec:
>
>
> (rec {
> foo = ...
> bar = foo
Hi Mathijs,
I've not fully read the thread, but just so you know overrides are done with a
special attribute called __overrides, which has a more confusing semantics than
simply a rec. See
https://github.com/NixOS/nix/blob/master/src/libexpr/eval.cc#L525 for some
documentation, and the surroun
Excerpts from Mathijs Kwik's message of Fri Jul 06 11:53:28 +0200 2012:
> packageOverrides = pkgs:
> { foo = "string";
> bar = pkgs.foo + " concatenation";
> };
solution a) use rec:
(rec {
foo = ...
bar = foo
;
})
solution b,c )
use let recursion or fix function (which
On Fri, Jul 6, 2012 at 1:43 PM, Kirill Elagin wrote:
> Yeah, now I get your problem.
> It think, it's clear from the source of `applyGlobalOverrides` and from
> comments, that your `packageOverrides` is called with _original,
> non-overriden_ pkgs. This way you can to refer to _original_ attribute
Yeah, now I get your problem.
It think, it's clear from the source of `applyGlobalOverrides` and from
comments, that your `packageOverrides` is called with _original,
non-overriden_ pkgs. This way you can to refer to _original_ attributes
when overriding them.
I think the only option is to manuall
Maybe I better explain what I'm trying to achieve.
I have a bunch of packages and overrides that aren't very useful for
others, so I can't commit them to nixpkgs.
I don't want to constantly maintain my own "fork" that I need to keep
up-to-date, but rather use the current "channels" functionality.
On Fri, Jul 6, 2012 at 12:01 PM, Kirill Elagin wrote:
> rec is the answer (this is something like let/letrec in Lisp, if you know
> what I mean ;) ).
I don't see how rec would help here.
As I understand it, rec helps when an attrset has attributes that
refer to each other.
But in this case, bar i
rec is the answer (this is something like let/letrec in Lisp, if you know
what I mean ;) ).
--
Кирилл Елагин
2012/7/6 Mathijs Kwik
> Hi all,
>
> I was reading this interesting piece of all-packages.nix
> (comments/whitespace removed):
>
> applyGlobalOverrides = overrider:
> let
> o
Hi all,
I was reading this interesting piece of all-packages.nix
(comments/whitespace removed):
applyGlobalOverrides = overrider:
let
overrides = overrider pkgsOrig //
(lib.optionalAttrs (pkgsOrig.stdenv ? overrides && crossSystem
== null) (pkgsOrig.stdenv.overrides pkgsOrig))
17 matches
Mail list logo
