On Mon, Mar 7, 2016 at 1:00 PM, Anderson Torres
wrote:
> 2016-03-07 1:21 GMT-03:00 stewart mackenzie :
>> It would be nice to have 3 things.
>>
>> 1) a more powerful substituteInPlace, ie a regexInPlace.
>
> I think we can just use a type of 'sed' in the text - it would be very
> powerful! But I d
2016-03-07 1:21 GMT-03:00 stewart mackenzie :
> It would be nice to have 3 things.
>
> 1) a more powerful substituteInPlace, ie a regexInPlace.
I think we can just use a type of 'sed' in the text - it would be very
powerful! But I don't know if it is viable. Also, because
"substituteInPlace" is ju
It would be nice to have 3 things.
1) a more powerful substituteInPlace, ie a regexInPlace.
2) "patchShebangs" for arbitrary strings in a file
3) Have an nix API for automation. A program can drive Nix.
/sjm
___
nix-dev mailing list
nix-dev@lists.scienc
Many thanks - I suppose I knew I should have been cautious about wiki docs
(at least, I think that's where I saw it - or maybe I just screwed up).
On Sun, Mar 6, 2016 at 3:19 PM, Arseniy Seroka wrote:
>
> 2016-03-06 19:43 GMT+03:00 Brandon Barker :
>
>> nix-shell -f ~/nixpkgs cobraEnv.nix
>
>
>
That's effectively what happens already, if you use nix-shell.
I'm concerned mostly about users who don't know to do that. Someone trying
to run a script from a different brand of unix, for example.
In theory, if there is a java binary on the PATH, there should also be a
JAVA_HOME. That's Oracle'
2016-03-06 8:37 GMT+01:00 Roger Qiu :
> Suppose this means I should maintain my own binary cache?
>
Why would you think so? There is a "binary cache" in your /nix/store. To
use it from another machine, you can use ssh_substituter_host
btw, please use "Reply-All" to stay on-list.
_
2016-03-06 19:43 GMT+03:00 Brandon Barker :
> nix-shell -f ~/nixpkgs cobraEnv.nix
You are doing wrong. You need to write
`nix-shell -I nixpkgs=~/nixpkgs cobraEnv.nix`
--
Sincerely,
Arseniy Seroka
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
What if the JRE(s) also included a `java-env.sh` that can be sourced ? Then
it's easy to build wrappers that source it dynamically.
On Sat, 5 Mar 2016 at 17:34 Svein Ove Aas wrote:
> Context: https://github.com/NixOS/nixpkgs/issues/13653
>
> There are a few packages which can't be considered pro
Actually, I assume ignoring broken packages is the default, so I'm probably
doing something wrong. I don't want broken packages installed, especially
if they are apparently completely unrelated to what I'm working on. For
example, I'm trying to test a package that I confirmed will build in my
forke
On 03/06/2016 02:14 PM, Kosyrev Serge wrote:
> Vladimír Čunát writes:
>> On 03/06/2016 01:10 PM, Matthias Beyer wrote:
>>> I want to remove old system generations and GC the packages, _without_
>>> removing
>>> anything else but these generations and their packages.
>>
>> I would `nix-store --gc
On 03/06/2016 01:10 PM, Matthias Beyer wrote:
> I want to remove old system generations and GC the packages, _without_
> removing
> anything else but these generations and their packages.
I would `nix-store --gc --print-dead` before and after deleting the
generations, and then I would use `comm`
Hi,
I want to remove old system generations and GC the packages, _without_ removing
anything else but these generations and their packages.
How to do this?
--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer
Proudly sent with mutt.
Happily signed with gnupg.
signature.asc
Description: P
12 matches
Mail list logo
