Re: [Nix-dev] Git commit hashes
On Tue, Jun 2, 2015 at 12:24 PM, Vladimír Čunát wrote: > On 06/02/2015 08:54 PM, Colin Putney wrote: > > Not using fetchgit, since the nix expressions are part of the code. > > Passing the commit hash into the script would require wrapping all my > > build commands. Not sure how that would work with nixops. That might be > > the best option, though. Thanks! > > If you use src = ./.; or something like that, you likely have .git > directory accessible to your builder already. With that you can do > whatever you need. > > Nixos needs the version accessible also as a nix value (i.e. during > *.nix evaluation already), so it needs to export the sha into a file > before running nix and just read the file (nixos-rebuild takes care of > that). > Ah, very helpful, thanks. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git commit hashes
On 06/02/2015 08:54 PM, Colin Putney wrote: > Not using fetchgit, since the nix expressions are part of the code. > Passing the commit hash into the script would require wrapping all my > build commands. Not sure how that would work with nixops. That might be > the best option, though. Thanks! If you use src = ./.; or something like that, you likely have .git directory accessible to your builder already. With that you can do whatever you need. Nixos needs the version accessible also as a nix value (i.e. during *.nix evaluation already), so it needs to export the sha into a file before running nix and just read the file (nixos-rebuild takes care of that). Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git commit hashes
On Tue, Jun 2, 2015 at 9:36 AM, Tomasz Kontusz wrote: > You can pass leaveDotGit = true into fetchgit, or pass the commit into the > build script as a separate variable. > Not using fetchgit, since the nix expressions are part of the code. Passing the commit hash into the script would require wrapping all my build commands. Not sure how that would work with nixops. That might be the best option, though. Thanks! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git commit hashes
On Tue, Jun 2, 2015 at 9:33 AM, Vladimír Čunát wrote: > Hi. > > On 06/02/2015 06:15 PM, Colin Putney wrote: > > I'm running a small cluster with several custom-built services, and I'd > > like to include git commit hashes in my logs so that I can easily find > > the source code that's producing them. I thought this would be > > straight-forward, but it's turning out to be surprisingly difficult. > > Do you know config.system.nixosVersion? > That variable should be usable when generating config for nixos services. > I'm trying to get the commit hash of *my own* software, which I'm installing on nixos, not the version of nixos that I'm installing into. Still, it looks like nixos has solved this problem, somehow. Thanks for the pointer. Colin ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git commit hashes
Colin Putney napisał: >On Tue, Jun 2, 2015 at 9:15 AM, Colin Putney >wrote: > >> Hi all, >> >> I'm running a small cluster with several custom-built services, and >I'd >> like to include git commit hashes in my logs so that I can easily >find the >> source code that's producing them. I thought this would be >> straight-forward, but it's turning out to be surprisingly difficult. >> >> Running `git describe` >> > >Ugh, premature send. Sorry. > >In principle, including the git hash in the output of a build should be >deterministic: for any given working copy, there is one and only one >commit >hash. In practice, though, running git describe without introducing >impurity seems to be impossible. Anybody figured out how to do this? You can pass leaveDotGit = true into fetchgit, or pass the commit into the build script as a separate variable. >Colin > > > > >___ >nix-dev mailing list >nix-dev@lists.science.uu.nl >http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Wysłane za pomocą K-9 Mail. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git commit hashes
Hi. On 06/02/2015 06:15 PM, Colin Putney wrote: > I'm running a small cluster with several custom-built services, and I'd > like to include git commit hashes in my logs so that I can easily find > the source code that's producing them. I thought this would be > straight-forward, but it's turning out to be surprisingly difficult. Do you know config.system.nixosVersion? That variable should be usable when generating config for nixos services. Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git commit hashes
On Tue, Jun 2, 2015 at 9:15 AM, Colin Putney wrote: > Hi all, > > I'm running a small cluster with several custom-built services, and I'd > like to include git commit hashes in my logs so that I can easily find the > source code that's producing them. I thought this would be > straight-forward, but it's turning out to be surprisingly difficult. > > Running `git describe` > Ugh, premature send. Sorry. In principle, including the git hash in the output of a build should be deterministic: for any given working copy, there is one and only one commit hash. In practice, though, running git describe without introducing impurity seems to be impossible. Anybody figured out how to do this? Colin ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Git commit hashes
Hi all, I'm running a small cluster with several custom-built services, and I'd like to include git commit hashes in my logs so that I can easily find the source code that's producing them. I thought this would be straight-forward, but it's turning out to be surprisingly difficult. Running `git describe` ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] tests with meta section
Yes please, I'd like to receive emails for failing tests, too.
On Tue, Jun 2, 2015 at 9:17 AM, Joachim Schiele wrote:
> hi,
>
> wouldn't it be helpful if the unit tests in release.nix, like these:
>
> # Run the tests for each platform. You can run a test by doing
> # e.g. ‘nix-build -A tests.login.x86_64-linux’, or equivalently,
> # ‘nix-build tests/login.nix -A result’.
> tests.avahi = callTest tests/avahi.nix {};
> tests.bittorrent = callTest tests/bittorrent.nix {};
> tests.blivet = callTest tests/blivet.nix {};
> tests.cadvisor = hydraJob (import tests/cadvisor.nix { system =
> "x86_64-linux"; });
> tests.chromium = callTest tests/chromium.nix {};
> ...
>
> would also contain a meta section with maintainer, so if a tests fails
> on hydra, i get an email?
>
> regards,
> joachim
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
--
NixOS Linux
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] tests with meta section
hi,
wouldn't it be helpful if the unit tests in release.nix, like these:
# Run the tests for each platform. You can run a test by doing
# e.g. ‘nix-build -A tests.login.x86_64-linux’, or equivalently,
# ‘nix-build tests/login.nix -A result’.
tests.avahi = callTest tests/avahi.nix {};
tests.bittorrent = callTest tests/bittorrent.nix {};
tests.blivet = callTest tests/blivet.nix {};
tests.cadvisor = hydraJob (import tests/cadvisor.nix { system =
"x86_64-linux"; });
tests.chromium = callTest tests/chromium.nix {};
...
would also contain a meta section with maintainer, so if a tests fails
on hydra, i get an email?
regards,
joachim
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [PATCH] Add a ‘verifyStore’ RPC
Hi, On 01/06/15 23:20, Ludovic Courtès wrote: > The patch below adds a ‘verifyStore’ RPC with the same signature as the > current LocalStore::verifyStore method. Thanks! I've applied this with the following change to disallow repairing by unprivileged users (since it's a potentially dangerous operation): https://github.com/NixOS/nix/commit/d8ddf994e70f97994e0f1fbd382df93cd071b90f -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] override a haskellngPackage in shell.nix
Hi Cody,
here is a "shell.nix" file that does what you want:
| with (import {}).pkgs;
|
| let
|
| haskellPackages = haskell.packages.ghc7101.override {
| overrides = self: super: {
| transformers = self.transformers_0_4_3_0;
| };
| };
|
| pkg = { mkDerivation, base, stdenv, transformers }:
| mkDerivation {
| pname = "mtl";
| version = "2.2.1";
| sha256 = "1icdbj2rshzn0m1zz5wa7v3xvkf6qw811p4s7jgqwvx1ydwrvrfa";
| buildDepends = [ base transformers ];
| homepage = "http://github.com/ekmett/mtl";;
| description = "Monad classes, using functional dependencies";
| license = stdenv.lib.licenses.bsd3;
| };
|
| drv = haskellPackages.callPackage pkg {};
|
| in
|
| drv.env
$ nix-shell --command "ghc-pkg list transformers"
/nix/store/3pqlvxkj1nsj02gyw3qr0nd9mvs64nvf-ghc-7.10.1/lib/ghc-7.10.1/package.conf.d:
transformers-0.4.2.0
transformers-0.4.3.0
Please note that http://wiki.ocharles.org.uk/Nix describes this kind of
setup, too, in the section "Multiple Project Usage".
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-shell for a custom haskell library
Hi Dmitry,
> The way I've used nix-shell for some haskell packages before was
> something like that:
>
> nix-shell -p '(haskellPackages.callPackage ./default.nix { })' --command
> 'builtExecutable'
I see no reason why that command shouldn't continue to work just as
before. If your "default.nix" uses valid syntax, etc., then this
approach should work just fine.
> And here is an example of one of that old-way-haskell-packages
> expressions:
>
> { pkgs ? (import {}) }:
>
> let biegunka = import ./biegunka.nix {}; in
>
> pkgs.haskellPackages.cabal.mkDerivation (self: {
> [...]
> })
>
> Nowadays, there is no more `haskellPackages.cabal.mkDerivation`.
Right, there is not. You'll have to adapt the build instructions for the
new code. The easiest way to do that is to just generate the expression
with cabal2nix. For example, let's build and run the program "hlint":
$ nix-shell -p "haskellPackages.callPackage ( $(cabal2nix cabal://hlint) ) {}"
--command "hlint --version"
HLint v1.9.21, (C) Neil Mitchell 2006-2015
Alternatively, you can also build the source code with "cabal":
$ nix-env -iA haskellPackages.cabal-install
$ nix-shell "" -A haskellPackages.hlint.env
[nix-shell:/tmp]$ cabal get hlint-1.9.21
[nix-shell:/tmp]$ cd hlint-1.9.21
[nix-shell:/tmp/hlint-1.9.21]$ cabal run hlint -- --version
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring hlint-1.9.21...
[... lots of compiler messages omitted ...]
Linking dist/build/hlint/hlint ...
Running hlint...
HLint v1.9.21, (C) Neil Mitchell 2006-2015
If you want to go all out, you can even build the package in a *pure*
environment:
$ nix-shell --pure "" -A haskellPackages.hlint.env
[nix-shell:/tmp]$ cd /tmp/hlint-1.9.21
[nix-shell:/tmp/hlint-1.9.21]$ runhaskell Setup.hs build
[... lots of compiler messages omitted ...]
In-place registering hlint-1.9.21...
Preprocessing executable 'hlint' for hlint-1.9.21...
[nix-shell:/tmp/hlint-1.9.21]$ dist/build/hlint/hlint --version
HLint v1.9.21, (C) Neil Mitchell 2006-2015
If you want to do this stuff with a package that's not registered on
Hackage, then the command "cabal2nix --shell" can generate a suitable
environment for you:
$ cd ~/src/my-package
$ cabal2nix --shell . >shell.nix
$ nix-shell --command "cabal run my-package -- --my-flag"
If you have cabal2nix version 20150531 or later from the current Nixpkgs
"master" branch, then you can even use "nix-build" on that generated
shell.nix file:
$ nix-build shell.nix
[... lots of compiler messages omitted ...]
$ result/bin/my-package --my-flag
There's half a dozen ways to accomplish what you want, you just have to
pick the one that's most convenient for you.
>> nix-shell --command "cabal configure && cabal build".
>
> Yeah, but the problem with this approach is some kind of lack of an
> isolation, since the path where the packages are being installed into
> is shared:
>
> /Users/m/.ghc/x86_64-darwin-7.10.1/package.conf.d
> engine-io-1.2.6
cabal configure accepts a "--prefix" argument that let's you put the
installed files into any location you please. Besides, it's usually
unnecessary to install the programs in the first place. You can run them
in-place with "cabal run", or you simply execute the binary after the
build step directly from the dist/build/ directory.
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix Windows support
Hi Rok, That's very good news! I will try it out when I find the time this week. N. On Tue, Jun 2, 2015 at 10:25 AM Rok Garbas wrote: > Quoting Nathan Bijnens (2015-05-22 14:55:35) > > What's the state of Nix on Windows? > > > > How hard would it be to get the nixops command working on Windows, to > provision > > Nixos hosts in the cloud? > > > > hi nathan, > > nix (current master) is building again on cygwin since 2 weeks now. > > i'm slowly going through packages and adding patches to make them compile > on > cygwin as well. but i think some extra work would need to be put in nixops > to > be able to provision nixos hosts. > > windows support (via cygwin) is slowly coming back. > > > -- > Rok Garbas - http://www.garbas.si > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix Windows support
Quoting Nathan Bijnens (2015-05-22 14:55:35) > What's the state of Nix on Windows? > > How hard would it be to get the nixops command working on Windows, to > provision > Nixos hosts in the cloud? > hi nathan, nix (current master) is building again on cygwin since 2 weeks now. i'm slowly going through packages and adding patches to make them compile on cygwin as well. but i think some extra work would need to be put in nixops to be able to provision nixos hosts. windows support (via cygwin) is slowly coming back. -- Rok Garbas - http://www.garbas.si signature.asc Description: signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
