This is a clever optimization. Thank you Oliver.
--
aycan
> On 22 Apr 2016, at 21:33, Oliver Charles wrote:
>
> It's certainly possible, because I just did it with Haskell ;)
>
> https://gist.github.com/ocharles/cbd5d7ce63bb570abb86e655f36435ab
>
>> On Fri, Apr 22, 2016 at 7:16 PM stewart mac
You will save me hours of waiting in the future, definitely beer worthy!
Much appreciated Oliver!
On 23 Apr 2016 02:33, "Oliver Charles" wrote:
> It's certainly possible, because I just did it with Haskell ;)
>
> https://gist.github.com/ocharles/cbd5d7ce63bb570abb86e655f36435ab
>
> On Fri, Apr 2
It's certainly possible, because I just did it with Haskell ;)
https://gist.github.com/ocharles/cbd5d7ce63bb570abb86e655f36435ab
On Fri, Apr 22, 2016 at 7:16 PM stewart mackenzie
wrote:
> Yeah, I'm not so sure it's possible because one cannot copy from a
> precompiled derivation output to a new
Yeah, I'm not so sure it's possible because one cannot copy from a
precompiled derivation output to a new derivation output, ie copy
cross derivation.
As these multiple outputs (outputs = [x y z]) are seen as different
derivations, this cannot happen right?
Have you actually managed to make progr
Ah, okay, I get your drift, I'll think how to make it succinct and
tidy in the code :-)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Well you don't tie the knot in the expression itself. It's more that the
pre-existing artefacts are a function input, and a function output:
{ stdenv, gcc, etc, artefacts ? null }:
{
preConfigure = "cp ${artefacts}/* .'';
outputs = [ "out" "artefacts" ];
}
Then you would nix-build to produce
Interesting Oliver, though this sounds like it'll throw a recursive
error. I'll investigate! cheers!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
http://nixos.org/nixpkgs/manual/ should answer all your questions regarding
Python :)
On Fri, Apr 22, 2016 at 4:59 PM, Marc Weber wrote:
> The question I have is which is the recommended way to install "scrapy
> along with dependencies", the following fixes it by making
> propagatedUserEnvPkgs e
Something I'm experimenting with here is to actually have these
intermediate artefacts be explicitly captured. I would use multiple outputs
to have both the normal complete binaries, and another output for .o files
and the like. Then you can feed this back in to future builds.
Does that help? Migh
The question I have is which is the recommended way to install "scrapy
along with dependencies", the following fixes it by making
propagatedUserEnvPkgs equal to propagatedBuildInputs.. is there another
way?
diff --git a/pkgs/development/python-modules/generic/default.nix
b/pkgs/development/pyth
My story is pretty similar to yours.
I first ran across Nix maybe... a year ago, or thereabouts. I don't
remember exactly how, but up until recently my Linux installs tended to
self-destruct once or twice a year, so I was always looking for alternative
(and ideally less breakable) distributions.
Thanks for the responses so far!
Let me see...
- I actually agree with Tomas about naming. I know I wrote
"services.monitoring.enable", but I hadn't put a lot of thought into that
sentence; "services.monitoring.prometheus" seems like a better namespace.
- I'd add battery life to the list of thin
That's interesting, however I don't think this should be part of
"monitoring" service.
I'm using prometheus daily and I'm following its development and I don't
think it's stable enough (for example backend/storage changes quite often),
and prometheus is far from 1.0 (stable).
I don't agree that s
13 matches
Mail list logo