Re: [Nix-dev] An issue regarding the default parameters of a function

[Harald van Dijk]

On 12/02/2016 12:11, Sergey Mironov wrote:
> Hi. I have an issue regarding the combination of two Nix features:
> default parameters ( f = {arg ? def } : ...) and arbitrary length
> parameters (f = args@{arg, ...} : ...). It looks like they doesn't
> work together silently. Here is the example from my code. I'd like the
> function make-nk-parser to tweak some of it's arguments and pass them
> downstream to the makeHaskell function. In particular, I want it to
> add 'nk' to the list of dependencies or make it the only dependency.
>
>
>  make-nk-parser = args@{buildDepends ? [], ...} :
>  makeHaskell (args // {
>  pname = "nk-parser";
>  buildDepends = args.buildDepends ++ [nk];
>  isExecutable = true;
>  });
>
> Unfortunately, this code doesn't work.

Right. This only makes buildDepends [], not args.buildDepends.

So you can simply use

  make-nk-parser = args@{buildDepends ? [], ...} :
  makeHaskell (args // {
  pname = "nk-parser";
  buildDepends = buildDepends ++ [nk];
  isExecutable = true;
  });

In buildDepends ++ [nk] here, buildDepends still refers to the argument, 
not the attribute, because the rec keyword was not used.

If you really need default arguments accessible from args, if you're 
using args somewhere else where you cannot control its buildDepends from 
being accessed, you can use // to combine default and explicitly 
specified arguments:

  make-nk-parser = explicitArgs : let
defaultArgs = { buildDepends = []; };
args = defaultArgs // explicitArgs;
  in makeHaskell (args // {
  pname = "nk-parser";
  buildDepends = args.buildDepends ++ [nk];
  isExecutable = true;
  });

Both of these might be easier to maintain than the workaround you've 
come up with, although yours is of course perfectly valid too.

Cheers,
Harald van Dijk
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] An issue regarding the default parameters of a function

[Shea Levy]

This is intentional: @-capture captures what was actually passed. You 
can always do something like: let args_ = args // { buildDepends = 
args.buildDepends or buildDepends; } if you really need this behavior.

On 2016-02-12 06:11, Sergey Mironov wrote:
> Hi. I have an issue regarding the combination of two Nix features:
> default parameters ( f = {arg ? def } : ...) and arbitrary length
> parameters (f = args@{arg, ...} : ...). It looks like they doesn't
> work together silently. Here is the example from my code. I'd like 
> the
> function make-nk-parser to tweak some of it's arguments and pass them
> downstream to the makeHaskell function. In particular, I want it to
> add 'nk' to the list of dependencies or make it the only dependency.
>
>
> make-nk-parser = args@{buildDepends ? [], ...} :
> makeHaskell (args // {
> pname = "nk-parser";
> buildDepends = args.buildDepends ++ [nk];
> isExecutable = true;
> });
>
> Unfortunately, this code doesn't work. I call make-nk-parser with
> empty arguments and Nix errors with "error: attribute ‘buildDepends’
> missing" near the args.buildDepends. In contrast, the following
> workaround works:
>
> make-nk-parser = args@{...} :
> let
> buildDepends = if args ? buildDepends then
> args.buildDepends else [];
> in
> makeHaskell (args // {
> pname = "nk-parser";
> buildDepends = buildDepends ++ [nk];
> isExecutable = true;
> });
>
> Is it a known bug or feature?
>
> Regards,
> Sergey
> ___
> 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] change in HEAD can render a system unbootable

[Michael Alan Dorman]

Since this is something of a hair-on-fire issue, I wanted to bring it up
on-list as well as in the bug tracker to make sure it gets some
exposure.

As reported in https://github.com/NixOS/nixpkgs/issues/12949, there's a
recent change in HEAD that requires some significant effort to recover
from.  It would be good to get the guilty change either reverted or
amended so it won't break things.

Mike.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] change in HEAD can render a system unbootable

[Michael Alan Dorman]

And of course, the moment I sent that I see that @peti did so.

Mike.

On Fri, Feb 12, 2016, at 07:18, Michael Alan Dorman wrote:
> Since this is something of a hair-on-fire issue, I wanted to bring it up
> on-list as well as in the bug tracker to make sure it gets some
> exposure.
> 
> As reported in https://github.com/NixOS/nixpkgs/issues/12949, there's a
> recent change in HEAD that requires some significant effort to recover
> from.  It would be good to get the guilty change either reverted or
> amended so it won't break things.
> 
> Mike.
> ___
> 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] Using Nix as the preferred package manager for a new language

[Philipp Hausmann]

Interestingly enough, we have some of the same questions for the Agda
programming language. Currently, Agda doesn't really have any package
manager, so there are no backwards-compatibility problems with using Nix.

It would be really nice if we could use Nix as the one-and-only package
management solution for Agda. However, Nix doesn't support Windows,
which means we need a second fallback solution. This is rather
unpleasant, but not a show stopper.

For Agda, I'm currently leaning towards defining a simple package json
format and a very basic build tool and to build Nix support on top of
that. Kind of like the Haskell packages.

I'm certainly interested in how you're solving this problems and I will
keep an eye on it, maybe I can steal some of your work and use it for
Agda ;-)

Cheers, Philipp

> Hi! I've tried to start this discussion a couple times on IRC, but it
> hasn't really gotten attention, so:
>
> I'm one of the developers of Monte, a new programming language. We don't
> want to write a package manager, because package managers are hard. (Also
> we've been watching npm happen for the past few years.) So we plan to use
> Nix. However, we've got some requirements for our package layout, and we
> haven't seen anybody else do all of the things we want at once. Here's
> what we're thinking:
>
> * Monte packages shouldn't live in nixpkgs. We use standalone Nix
> expressions to build stuff like our runtime, and it makes development very
> speedy since we do not have to round-trip our Nix changes through nixpkgs.
> We also want to keep Nix expressions for packages close to the packages
> themselves (see next point.) Perhaps when our ecosystem has developed
> more, we can revisit this.
>
> * Monte packages should bundle their own Nix expressions. Our reasoning is:
>
> ** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
> contains a Nix expression for building some or all of the Monte runtime
> and packages. However, now we've decoupled the description of the packages
> from the packages themselves, which makes maintaining the package harder,
> since changes to the package require a corresponding change to mtpkgs. We
> didn't gain anything over just using nixpkgs!
>
> ** Okay, so instead we make a JSON (or whatever) description of each
> package, and ship that with the package. Then, we interpret that
> description as a Nix expression, and do Nix things as usual. Except that
> this doesn't work, because now the JSON description is a new package
> manager format! We didn't want that.
>
> ** So it seems like packages should ship with a Nix expression.
>
> * Packages should be easy to cargo-cult. This might sound weird, but my
> experience in other ecosystems (especially Python and Perl) has taught me
> that most package descriptions are cargo-culted from other similar
> packages. We should have a very custom Nix derivation-producing function
> which turns a minimal Nix expression into a full Monte package
> description.
>
> So with that in mind, here's where we currently are. We have a runtime and
> some packages. There's a terrible terrible Nix function that generates
> derivations (
> https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
> ). An example usage is (
> https://github.com/monte-language/mt-rational/blob/master/default.nix ).
>
> As you can see, our derivations are not especially good. We don't have a
> good way to locate a runtime so that we can call ``montePackage`` easily.
> Once our packages start depending on other Monte packages, the problem
> will only be worse. We also have this indirect dependency on nixpkgs for
> library stuff, which is worse than a direct dependency or no dependency at
> all.
>
> We're seeking any advice on how to make this situation better. As far as
> we can tell, nobody else has tried to make Nix their first-class preferred
> package management solution for their language, so we are blazing trails
> here.
>
> Thanks!
> ~ C.



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Using Nix as a package manager (for yet another language)

[Marc Weber]

urweb requires C/C++ libraries (eventually).
AFAIK C/C++ package managers don't exist (dependency information) - they
are "encoded in configure scripts and whatnot" - for some universes
(gnome) there are dependency informations available eventually.

Thus for that use case nix is a good fit, because you can "provide a
working set of dependencies" within nixpkgs - and because nix also
forces you to have "one maintained set of packages". Eg hackage
theoretically allows infinite amount of combinations nobody can test in
real life.

All languages I know (Haskell, python, ruby) depend on C libraries and
thus partially suffer from such kind of problem - even Vim depending on
python and whatnot...

Thus yes: Nix is likely to provide results you can live with fast.

Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Using Nix as a package manager (for yet another language)

[Sergey Mironov]

Hi, List. I've just noticed a long topic regarding using NIx as a
package manager for a language. Сoincidentally, I use Nix for the same
purpose: I am working on packaging UrWeb libraries using Nix.

Here is the combinators library I wrote
[1] - https://github.com/grwlf/urweb-build/blob/master/default.nix
Here is an example of package recipe script
[2] - https://github.com/grwlf/urweb-soup/blob/master/build.nix

Nix-build works fine as a replacement for GNU Make. But here comes an
interesting question. What if I want to package a Nix-driven library
for NixOS ?? I don't know how to do it at the moment.

The problem is at the line 7 of [1]: I import  here.
Packaging this 'build-script' for NixOS means running nix-build from
the builder of mkDerivation, in pure environment where we do not have
NIX_PATH (am I right?). And AFAIK it is a top of an iceberg.

So what do you think, how to call nix-build from the mkDerivation's
build script and make it aware of the same Nixpkgs tree the top-level
nix-build (which runs current mkDerivation) uses?

Regards,
Sergey
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] An issue regarding the default parameters of a function

[Vladimír Čunát]

Hi.

On 02/12/2016 12:11 PM, Sergey Mironov wrote:
> I have an issue regarding the combination of two Nix features:
> default parameters ( f = {arg ? def } : ...) and arbitrary length
> parameters (f = args@{arg, ...} : ...).

@-pattern binds exactly what was *passed* to the function. Eelco
considers that a feature IIRC. There's been a discussion about this on a
couple of nix issues on github.

Personally, I would prefer to bind the attrmap after substituting
defaults, as that seems much more useful, but that would be a
non-compatible change to nix...

--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] Including binary-only derivation in nixops deploy.

[Oliver Charles]

If you're saying you want to install something knowing only the Nix store
path, you can do:

{ type = "derivation";
  name = "whatever";
  outputName = "out";
  outPath = builtins.storePath "/nix/store/deadbeefdeadbeef"; }

This will attempt to lookup the given store path in binary substitution
servers, and will fail if it can't be found (as Nix has no other way to
provide that output).

Does that help?


On Fri, Feb 12, 2016 at 3:03 AM Kevin Cox  wrote:

> Hello all. I have a possibly strange question but I was hoping that you
> could help me out. I am currently using nixops to manage a couple of
> servers and have a couple custom derivations for personal packages. While
> managing the derivation in my nixops config isn't terrible I wanted to
> manage the derivations in each project so that I can use nix to build the
> project in CI and use nix-shell for development. Another benefit of using a
> binary is that I know that dependencies won't change, and that the package
> has been tested with the exact dependencies it will be shipping to
> production.
>
> So long story short I have uploaded the derivation to a binary cache and I
> was hoping to use it in a nixops deploy. However I can't figure out how to
> get it to work (if it is possible). `nix-store
> -r /nix/store/01kymbkb0a1sc99y72wzn5b4gcjdlbnm-dontsayit-nginx` works fine,
> the package and all of its dependencies are installed to the local store.
> However I can't figure out how to use it in a nixops config.
>
> The naive approach of just including the path in a file (in my case an
> nginx config) doesn't work as it isn't being scanned for that path and the
> dependency doesn't get picked up. Interpolating it as a path also doesn't
> work as the file gets copied from the store and put into the store under a
> different hash, losing all dependency information.
>
> I tried playing around with .drv descriptions but couldn't figure out how
> to get it to work either.
>
> I would appreciate any help or recommendations for alternative solutions.
> ___
> 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] An issue regarding the default parameters of a function

[Sergey Mironov]

Thanks, It is clear. I would also vote for shorter code here.

Sergey

2016-02-12 14:21 GMT+03:00 Vladimír Čunát :
> Hi.
>
> On 02/12/2016 12:11 PM, Sergey Mironov wrote:
>> I have an issue regarding the combination of two Nix features:
>> default parameters ( f = {arg ? def } : ...) and arbitrary length
>> parameters (f = args@{arg, ...} : ...).
>
> @-pattern binds exactly what was *passed* to the function. Eelco
> considers that a feature IIRC. There's been a discussion about this on a
> couple of nix issues on github.
>
> Personally, I would prefer to bind the attrmap after substituting
> defaults, as that seems much more useful, but that would be a
> non-compatible change to nix...
>
> --Vladimir
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Including binary-only derivation in nixops deploy.

[Kevin Cox]

On Feb 12, 2016 6:54 AM, "Oliver Charles"  wrote:
>
> If you're saying you want to install something knowing only the Nix store
path, you can do:
>
> { type = "derivation";
>   name = "whatever";
>   outputName = "out";
>   outPath = builtins.storePath "/nix/store/deadbeefdeadbeef"; }
>
> This will attempt to lookup the given store path in binary substitution
servers, and will fail if it can't be found (as Nix has no other way to
provide that output).
>
> Does that help?
>

Thanks Oliver, that's exactly what I was looking for.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Wiki is dead

[Eelco Dolstra]

Hi,

On 10/02/16 18:52, zimbatm wrote:

> Is it possible to get a dump using dumpBackup.php ?
> https://en.wikipedia.org/wiki/Help:Export

I've put a dump at https://nixos.org/~eelco/wiki-20160212.xml.gz.

-- 
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] Using Nix as a package manager (for yet another language)

[stewart mackenzie]

If you don't mind I'll use this thread as the umbrella "nix as yet
another language package manager" issue thread.

I want to do this:

create a derivation that creates a shell file.
This shell file does one thing and one thing only: it creates a custom
virtual machine depending on the inputs of the flow-based programming
file.
(later I'll implement a recursive decent function which determines the
transitive deps of a flow-based programming file.

This fbp file consists of exactly two dependencies:
'maths_boolean:(boolean="true"' -> a nand(maths_boolean_nand) output
-> input disp(maths_boolean_print)
'maths_boolean:(boolean="true"' -> b nand()

1) maths_boolean_nand :
https://github.com/sjmackenzie/fractalide/tree/fractalide/components/maths/boolean/nand
2) maths_boolean_print :
https://github.com/sjmackenzie/fractalide/tree/fractalide/components/maths/boolean/print

Both of these libraries are shared libraries programmed in the Rust
programming language.


I need to ensure the below user experience:

$ git clone git://github.com/sjmackenzie/fractalide (fractalide branch)
$ nix-build  -> creates a sh file, and copies a snapshot
of the current state of the fractalide codebase to /nix/store/
$ ./result/bin/fvm ~/path/to/fbp/file.subnet---> pass the
fbp file to the sh script, the sh script compiles a custom virtual
machine with all the deps then
immediately executes the subnet

If the fvm is installed via
$ nix-env -iA nixos.fvm

whenever one runs
$ fvm ~/path/to/fvm.fbp (where the *.fbp has continuously changing
contents, a new fvm with exactly those deps are compiled, symlinked
then executed.)

This is what I have... and it sucks batshit:
The problem lies here:
https://github.com/sjmackenzie/fractalide/blob/fractalide/default.nix#L21

What am I doing wrong?

This approach allows fvm to be lazily evaluated, thus allowing the
repo to expand massively (similarly to nixpkgs) without having to
compile everything up front.
This is an extremely desirable feature, as rust compilation times are
cause for suicide.

>From a higher level: does anyone have a better suggestion on
approaching this kind of system? The we're all trail blazing and it
would be good to head bang.

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Checking rpaths for 32 bit on 64 bit

[Nikolay Amiantov]

Use glibc_multi, I think I've fixed its ldd some time ago to work
correctly for both 32-bit and 64-bit libraries.

On 02/12/2016 10:38 PM, Tony wrote:
> Hi!
> Does anyone know if there is something like ldd32 in NixOS I can use to
> check 32 bit dynamic executables on a 64 bit system.
> Thanks.
> 
> Kind Regards,
> Tony
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

-- 
Nikolay.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev