Re: [Nix-dev] Simplify node packages?

[Colin Putney]

On Tue, Apr 25, 2017 at 3:21 AM, Sander van der Burg 
wrote:

Now yarn (and other approaches such as ied) do obviously a much better job
> than NPM in some aspects. Unfortunately, as of today, NPM remains the
> de-facto standard for Node.js package deployment, and I'm not sure if this
> will ever change.
>

It's changing now and quite quickly. A google search for "yarn add" on
npmjs.com yields about 5K results[2]. Here's one random example[2] not
affiliated with Facebook . The installation instructions tell people to use
yarn. Or try searching for "yarn.lock" on Github[3. There are 128K results.

There are a few reasons to expect this to continue:

   - Yarn is developed and supported by Facebook. As the developers of
   React, Facebook plays a huge role in the Node community and yarn will get a
   lot of adoption just because it's the tool "blessed" by Facebook. Further,
   Facebook has the resources and incentive to push yard forward quickly.
   - NPM has been foundering for a while, and Yarn is just better. It's
   faster and more reliable and easy to adopt.
   - At some point, NPM Inc. will embrace yarn in order to keep control of
   the package registry, which is where they make their money.

This shift will take time, of course, and most developers are still using
npm for now. But it won't be long before "I can't install your package with
yarn" is a show-stopper bug that destroys the viability of a node project.

Ideally, whenever an NPM project works, node2nix should work as well.


And this is why the node-community shift towards yarn matters to us nixers.
Increasingly, node developers are going to care more about whether it works
yarn, not npm, and projects are going to built with and tested against
yarn. So if we want node packages to "just work" with nix, basing it on
yarn's behaviour will be the easiest way to do that.

Colin

[1]
https://encrypted.google.com/search?hl=en_q=_epq=yarn+add_oq=_eq=_nlo=_nhi===_qdr=all_sitesearch=npmjs.com_occt=any=images_filetype=_rights=#q=%22yarn+add%22+site:npmjs.com=en_qdr=all=20
[2] https://www.npmjs.com/package/miku
[3] https://github.com/search?q=yarn.lock=Code=%E2%9C%93
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Simplify node packages?

[Colin Putney]

On Tue, Apr 25, 2017 at 12:51 AM, Profpatsch  wrote:

> yarn is really just a 1:1 rewrite of node with lockfiles.
> I don’t know why people celebrate it so much,
> because it does exactly nothing differently apart from
> creating the lockfiles.
> Don’t even know why a rewrite was necessary.
>

There are 2 improvements:

   - lock file
   - caching of downloads

These address two huge pain points in the node world, not coincidentally
the ones that nix also fixes.

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

Re: [Nix-dev] Simplify node packages?

[Colin Putney]

On Sun, Apr 23, 2017 at 6:10 AM, Benno Fünfstück <
benno.fuenfstu...@gmail.com> wrote:


> * Alternatively, `yarn` claims to be more deterministic. Can we use `yarn`
> to build all NPM packages? Or are there NPM packages that are incompatible?
>

I think this is the best way forward. Yarn is *much* better than npm and is
being enthusiastically adopted by the node community. Whatever
compatibility issues that currently exist with yarn will soon be resolved.
(Nix users have basically no influence, but package maintainers can't
afford to ignore yarn users.)

Node2nix focusses on replicating the typical npm workflow so that "normal"
node developers experience minimal disruption. I think that's a worthy
goal, but it should be balanced against the need to fully exploit the
benefits of nix. For example, it seems to be impossible to override an npm
derivation to add a native dependency. That to, to me, is one of key
features of nix, but at the moment we can't use it. As yarn fixes more and
more of the more pedestrian issue with npm, integration with the nix
ecosystem and will become the only real advantage to using nix with node.

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

Re: [Nix-dev] Announcing: NixOS Security Team, and Request for Comments

[Colin Putney]

On Fri, Jan 6, 2017 at 11:01 AM, zimbatm  wrote:

> In relation to GPG key signing, I think it's safe to trust online
> identities it they are established trough enough channels. That's basically
> what keybase.io is doing, they are a point of contact but the proof of
> identity is distributed on multiple services. Personal verification is just
> another target.
>
> Someone who would want to subvert that process would have to Impersonate
> all these services through MITM and also maintain that in place if the user
> is moving between connections (and somehow not trigger chrome's certificate
> monitoring).
> As far as I know only state actors might be able to pull that off. But
> they also have access to zeroday to hack and extract the private key
> directly which seem more practical to me.
>
> Anyways, it's good that you want to be careful, that's just my thinking.
>
In this context, we don't actually care about identity much. If @rbvermaa
has a passport that says something other than "Rob Vermaas", it doesn't
really matter. What does matter is that we trust the person who committed
so much good code. To that end, maybe the security team should add their
keys to some file in the repository, and then cross-sign from a checkout.

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

Re: [Nix-dev] Usability: Nixpkg > NixOS

[Colin Putney]

On Thu, Dec 15, 2016 at 5:03 AM, Mark Gardner  wrote:


>
> ​
>
> ​Just like "Go" -> "golang", we can promote "Nix" -> "nixpkg".
>

Maybe nix-lang?

One thing I've noticed is that if nix is promoted as a package manager,
people are interested until they run into the fact that they have to learn
a weird functional language to use it effectively. Then they decide it's
"too complicated" and go invent an ad-hoc, informally-specified,
bug-ridden, slow implementation of half of nixpkgs. (See, for example,
http://snapcraft.io/)

Perhaps if we promote the language more, people will get over that hurdle
early and then be pleasantly surprised when they see what's possible with
it.

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

[Nix-dev] Great news for users of Node on NixOS

[Colin Putney]

https://code.facebook.com/posts/1840075619545360
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs

[Colin Putney]

On Thu, Jul 14, 2016 at 4:19 AM, Tomasz Czyż  wrote:


> Are you sure that having multiple tools/solutions is frustrating? Maybe
> it's just lack of description or documentation?
> (btw, currently there is only one, Sander is trying to introduce second
> "official" one if I understand situation correctly).
>

Actually, I think that in this case, two separate tools might be called
for. For dealing with the craziness that is npm, I see two approaches.

One is the nix-centric approach of the existing npm2nix: each package gets
its own derivation, and dependencies are symlinked into the node_modules
directory. That's simple fits most closely with the way native nix packages
work. The main problem with this is that npm does "clever" things to work
around problems with its design, and some npm packages have undeclared
dependencies that only work because of the quirks of npm. These packages
are fairly rare, but they do crop up from time to time.

The other approach is more npm-centric. The idea is to mimic the quirks of
npm as exactly as possible, so that all packages find themselves in exactly
the environment they expect. This leads to other problems, such as slower
execution and bloated derivations.

So it might actually be a good idea to have two different tools, each of
which make different engineering tradeoffs.

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

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Colin Putney]

On Wed, Jun 15, 2016 at 3:40 AM, Domen Kožar  wrote:

> Hydra NixOS module and package are now available on nixpkgs master.
> There's one bug I need to fix, then I'll backport these changes to 16.03.
>
> Meanwhile, I used following commit on 16.03 before I moved to the fork
> using some improvements:
> https://github.com/snabblab/snabblab-nixos/commit/20a3fe6e9cf9e0da2a855bd1df9ce7ebad434951
>
> Official releases will for now be pinned git revisions on nixpkgs,
> hopefully that will suffice for most of us.
>

Hooray! Thank you so much to all the people that contributed to this.

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

[Nix-dev] [JOB] Fullstack web developer

[Colin Putney]

Hi folks,

Hope this isn’t off-topic for the list. My company is looking for a mid-level 
or senior engineer to work on a sophisticated web application. It’s a pretty 
simple stack - React, Node and Postgres. We package everything with nix and 
deploy it to NixOS using Nixops. 

Note that we’re not looking for remote developers. We’re a small startup in San 
Francisco, and you’d be working out of our office in the Financial District. If 
you’re in the Bay Area or wiling to relocate, please contact me off-list, and I 
can give you more details. Thanks!

Colin



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

Re: [Nix-dev] Nixpkgs versioning

[Colin Putney]

> On Mar 30, 2016, at 1:55 AM, Jakob Gillich  wrote:
> 
> FYI npm also uses @ for this purpose (e.g. npm install foo@1.0). I don't
> think I ever had to escape it (?).

I don’t know about Guix, but with NPM, version names are much more important 
than they are with nix. NPM uses semver and constraint solving to resolve 
dependencies based on the version numbers, so the actual x.y.z number attached 
to a given release is critical. With nix, there’s no central registry of 
packages, release and their numbers, and we often specify dependencies with a 
Git rev and hash. We use fixed-output derivations to ensure that we always get 
the right dependency, so the version number of a given derivation doesn’t 
matter that much, and often doesn’t exist.

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

[Nix-dev] IED, an alternate package manager for node

[Colin Putney]

Looks interesting, and credits nix as an inspiration:

https://github.com/alexanderGugel/ied



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

Re: [Nix-dev] yet another npm2nix reengineering attempt

[Colin Putney]

On Tue, Mar 1, 2016 at 6:42 AM, Sander van der Burg 
wrote:


> So as you may see: it is all quite annoying and painful. :(
>

I'm starting to think that it's pointless to try to make it all work
automatically. At some point it's so compatible with npm that it replicates
all of npm's quirks and bugs and you might as well use npm directly,
because you're not enjoying any of the advantages of nix anymore.

What I've been trying to do is import dependency information from npm, but
make it easier to customize so that you can work around the quirks of
specific npm packages with less pain. I'm using the npm2nix in nixpkgs, but
ignoring the default.nix it generates, and building custom derivations from
the registry. It's still pretty painful when the generated registry doesn't
work, but I have managed to get things to work the nix way.

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

Re: [Nix-dev] Using nix-shell in messy trees with symlinks and binary files

[Colin Putney]

On Mon, Feb 15, 2016 at 11:39 PM, Kosyrev Serge 
wrote:

> Good day, folks!
>
> What I'm seeing is a rather disturbingly odd, context-depenent behavior of
> nix-shell:
>
> ,
> | [deepfire@andromedae:~/src/foo]$ nix-shell default.nix
> | warning: dumping very large path (> 256 MiB); this may run out of memory
> | error: file ‘/home/deepfire/src/foo/generated/rootfs/chroot/dev/fuse’
> has an unsupported type
> | (use ‘--show-trace’ to show detailed location information)
> |
> | [deepfire@andromedae:~/src/foo]$ mv default.nix scripts/
> |
> | [deepfire@andromedae:~/src/foo]$ nix-shell scripts/default.nix
> |
> | [nix-shell:~/src/foo]$
> `
>
> The directory structure, indeed, has some oddities -- device files,
> symlink loops, this kind of stuff.
>
> Consideration that nix-shell tries to compute some.. hash.. out of it all,
> sends shivers down my spine.  That's a lot of stuff to hash through.
>
> If this theory is, indeed, correct, what would be the way to make
> nix-shell disregard certain paths from the equation?
>

The problem here is that nix is trying to copy a large part of your
filesystem into the nix store. It does that when nix expressions refer to
files that aren't in the nix store. A derivation can only depend on other
derivations, so if you include data that isn't in the store, there's an
implicit derivation created that contains it. What you need to do is find
these implicit references and make them explicit - eg using the filterSrc
builtin. That will both speed up evaluation, because you'll be copying much
less data, and enable you to avoid these errors related to unsupported file
types.

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

Re: [Nix-dev] New NixOS and nixpkgs for SmartOS images released

[Colin Putney]

Bravo! Nix and SmartOS are such a natural match. I'm really glad to see
this!


On Mon, Feb 1, 2016 at 7:18 AM, deCube.net | Danny Wilson 
wrote:

> Hi list!
>
> Today I’m excited to announce 2 new images available for running nix on
> SmartOS:
>
>
> 1) NixOS as lx-branded zone:
>
> Running NixOS in SmartOS’ container native
> linux-system-call-table-emulated environment:
> https://wiki.smartos.org/display/DOC/LX+Branded+Zones
> Special thanks to Eelco for helping me at NixCon figure out the special
> NixOS (and udev) settings to make it work!
>
> I’ve tried NixOS 16.03-unstable as well, but that version systemd is too
> new for SmartOS at the moment and doesn’t boot.
>
> Available here:
> - http://datasets.at/ui/#!/configure/22ba59c6-8c49-11e5-87e5-7fbffbc05623
>
>
>
> 2) Nix with nixpkgs-unstable git checkout, bootstrapped for SmartOS:
>
> Version 0.2.0:
>
> Available here:
> - http://datasets.at/ui/#!/configure/a33de196-c865-11e5-aa1c-073507bee650
>
> Most notable changes since 0.1.0:
> - Nix 1.11.1 stable!
> - Built with official nixpkgs repository checkout.  (no more fork!)
> - Bootstrapped with this checkout to be exact:
> https://github.com/NixOS/nixpkgs/tree/2c78c7b84b45e9289e4b71abb4b36d95d58579fe
>
>
>
> Happy to help anyone willing to try these images :-)
>
> Thanks to the nix community for accepting my pull-requests and being
> awesome.
>
> ___
> 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] nix-shell with system pkgs

[Colin Putney]

On Mon, Jan 25, 2016 at 3:15 PM, Yacine Hmito 
wrote:


> So, after this lengthy introduction, these are my questions:
>
> - Is it possible for nix-shell to use pkgs as configured by the system
> instead of evaluating ''? Would pointing toward the system's .drv
> file
> help? If so, how should I proceed?
> - If it is not possible (yet ? :P), can someone explain to me why
> myotherpkg
> can't find its dependency? This really doesn't make sense to me.
>
> Thanks to anyone who'll be kind enough to answer, and to anyone how has
> made
> this awesome OS.
>

I'm not sure I understood what you're trying to accomplish, but it sounds
like you ought to be able to just do something like this:

Have nixpkgs in your NIX_PATH point to the unstable channel. Something like


NIX_PATH=nixpkgs=$HOME/.nix-defexpr/channels/nixpkgs-unstable


Then import that in your mypkg.nix file:

let

  pkgs = import  {};

  other = pkgs.callPackage ./myotherpkg.nix {};

in pkgs.stdenv.mkDerivation {...}


Finally, invoke your shell using your derivation directly:

> nix-shell mypkg.nix


Hope this helps!

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

Re: [Nix-dev] nix-shell with system pkgs

[Colin Putney]

On Tue, Jan 26, 2016 at 9:03 AM, yacine.hmito 
wrote:

> Thanks for the answer.
>
> What I am trying to achieve is using nix-shell from a custom derivation.
> Not a specific one (your solution is on point for that) but any derivation
> in a set.
>
> I achieved this as I explain in the first message. The problem is that the
> way I did it, derivations cannot depend on each other. I don't understand
> why.
>
>
Ah, ok. Then you want something like this:

in custompkgs.nix:

let

  pkgs = import  {};

  callPackage = pkgs.lib.callPackageWith allPkgs;

  allPkgs = pkgs // {

mypkg = callPackage ./mypkg.nix {};

otherpkg = callPackage ./otherpkg.nix {};

  };

in allPkgs


In mypkg.nix:

{ stdenv, otherpkg }:

  stdenv.mkDerivation { inherit otherpkg; ... }

Then invoke the shell like this:

> nix-shell custompkgs.nix -A mypkg



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

Re: [Nix-dev] [RFC] Generating documentation from nixpkgs (markdown files) with pandoc (Was: Real documentation, aka "Let's kill the wiki")

[Colin Putney]

On Wed, Nov 18, 2015 at 9:51 AM, Domen Kožar  wrote:

> I've once experimented and ported nixpkgs manual to
> http://static.domenkozar.com/nixpkgs-manual-sphinx-exp/
>

Wow, that looks great! This kind of thing is much nicer than the docs
currently on the web site. With everything in one page it's hard to find,
link to and search for specific sections that have the information you
want. This solves that problem nicely.


> But there doesn't seem to be of a much interest to make documentation more
> approachable (something we did with github for code)
>

 Isn't this thread an expression of interest?

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

Re: [Nix-dev] What is the end game?

[Colin Putney]

On Mon, Aug 31, 2015 at 1:26 AM, Peter Simons  wrote:

> Hi Colin,
>
>  > That seems backwards. The upstream project would then depend on nixpkgs.
>
> the upstream project depends on Nixpkgs because it most likely needs a
> compiler and a libc and some other core utils to build. Where are those
> expressions supposed to come from without depending on Nixpkgs?
>

Anywhere you like! It could depend on nixpkgs, sure. Or you could have your
own library of nix expressions for dependencies. Or there could be another
shared repository for dependencies, perhaps around a particular programming
language or use-case. Nix is a good way of specifying dependencies,
regardless of where the those specifications come from. An upstream project
that wants to use nix should not have to depend on nixpkgs just to build.

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

Re: [Nix-dev] What is the end game?

[Colin Putney]

On Sun, Aug 30, 2015 at 11:09 AM, Peter Simons sim...@cryp.to wrote:

 Hi Daniel,

   What if binutils had a release.nix in its repo? How about gcc or
   clang? What would the expressions look like in nixpkgs?

 the expressions in Nixpkgs would look exactly like they do today, i.e.
 they download a release tarball and build it. The binutils release.nix
 file would then customize those expressions with overrideDerivation or
 some other appropriate mechanism to build developer versions instead,
 i.e. by switching the 'src' location to a Git repository etc.


That seems backwards. The upstream project would then depend on nixpkgs.

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

Re: [Nix-dev] Some beginner Nix/nixpkgs questions

[Colin Putney]

On Wed, Aug 5, 2015 at 4:53 AM, Alex Dean a...@snowplowanalytics.com
wrote:


 On reproducible deployments using git revisions - it solves the problem,
 but it feels like a very out-of-band solution.


You don't have to embed a git revision in your nix expressions; I don't
like that solution much either. What we do at BetterCompany is always refer
to nixpkgs by an expression like import nixpkgs {}.  Then we have
$NIX_PATH include nixpkgs=~/.nix-defexpr/channels/nixpkgs. That means we
can manage our version of nixpkgs using nix-channel.

More generally, we include a default.nix and shell.nix in the root
directory of all our repositories, and then have another repository similar
to nixpkgs that bundles everything up, provides library functions etc.
That's also in $NIX_PATH, so we can use import ourpkgs {} to get access
to cross-repository dependencies, custom derivations functions etc.

Finally, we tie it all together with Hydra, Nixops and a bit of custom code
to help with deployments.

Hope this helps, and I'm happy to go into more detail if you have specific
questions.

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

Re: [Nix-dev] Nix-env error

[Colin Putney]

On Fri, Jul 24, 2015 at 11:16 PM, James Cook james.c...@utoronto.ca wrote:

I can't reproduce this at commit 554cbe9. The only thing that comes to
 mind is per-user configuration such as ~/.nixpkgs/config.nix, if
 you're sharing that between your computers. If that's a possibility, I
 guess you could try creating a new user and see if that user has the
 same problem. Good luck :-)


It turned out to be a mix of old and new versions of nixpkgs:


   - There was a symlink at ~/.nix-defexpr/channels_root
   - It pointed into /nix/var/nix/profiles/per-user/root/channels.
   - That, in turn, had a link
   to /nix/store/5n6dd7i1h3anw017paxm27mwaq4aaj8p-nixos-14.12.471.1f09b77/nixos
   ,
   - As Luca mentioned, that's an old nixpkgs.
   - It would have been fine, but for the fact that
keybase-node-client/default.nix
   imports nixpkgs,
   - Which ends up being the latest nixpkgs, set by my $NIX_PATH.
   - So node modules from the latest nixpkgs get built against a nodejs
   derivation from 7 months ago.
   - Error

Deleting ~/.nix-defexpr/channels_root solved it for me.

Just as a follow up, is it a bug that nix-env --show-trace -qa didn't show
the trace?

Thanks for the help,

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

Re: [Nix-dev] Nix-env error

[Colin Putney]

On Fri, Jul 17, 2015 at 3:08 PM, Luca Bruno lethalma...@gmail.com wrote:

 You have an old nixpkgs.


Hmm. As far as I can tell, I've got the latest nixpkgs-unstable. Commit
554cbe9 was created just a few days ago.

[dev@sandbox:~]$ echo $NIX_PATH
nixpkgs=/home/dev/.nix-defexpr/channels/nixpkgs:alia=/home/dev/work/alia/nix:ephemeral=/home/dev/work

[dev@sandbox:~]$ nix-channel --list
nixpkgs http://nixos.org/channels/nixpkgs-unstable

[dev@sandbox:~]$ nix-channel --update
downloading Nix expressions from ‘
http://nixos.org/releases/nixpkgs/nixpkgs-15.07pre66093.554cbe9/nixexprs.tar.xz
’...
  % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
 Dload  Upload   Total   SpentLeft
 Speed
100 4996k  100 4996k0 0   418k  0  0:00:11  0:00:11 --:--:--
 514k
unpacking channels...

[dev@sandbox:~]$ nix-env -qa
error: attribute ‘interpreterName’ missing, at
/home/dev/.nix-defexpr/channels/nixpkgs/pkgs/development/web/nodejs/build-node-package.nix:7:16

[dev@sandbox:~]$ realpath
/home/dev/.nix-defexpr/channels/nixpkgs/pkgs/development/web/nodejs/build-node-package.nix
/nix/store/4dzcgj50vw7s47wyf8fqsikxldc8b3z2-nixpkgs-15.07pre66093.554cbe9/nixpkgs/pkgs/development/web/nodejs/build-node-package.nix


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

[Nix-dev] Nix-env error

[Colin Putney]

Hi folks,

I'm running into an error I can't figure out.

# nix-env -i lsof
error: attribute ‘interpreterName’ missing, at
/root/.nix-defexpr/channels/nixpkgs/pkgs/development/web/nodejs/build-node-package.nix:7:16


I've run into it on a few different machines, and have usually worked
around it by some combination of switching/updating channels and fiddling
with my NIX_PATH.

I suspect though, that it has something to do with my particular setup. If
nixpkgs-unstable universally broke nix-env, that would get noticed and
fixed right away.

Any ideas about what could cause this?

Thanks,

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]

On Tue, Jun 2, 2015 at 9:33 AM, Vladimír Čunát vcu...@gmail.com 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]

On Tue, Jun 2, 2015 at 9:36 AM, Tomasz Kontusz tomasz.kont...@gmail.com
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

[Nix-dev] Git commit hashes

[Colin Putney]

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] Git commit hashes

[Colin Putney]

On Tue, Jun 2, 2015 at 9:15 AM, Colin Putney co...@wiresong.com 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

Re: [Nix-dev] Overriding a node package

[Colin Putney]

This happens when you have dependencies in package.json that are not
supplied by the dependencies passed to buildNodePackage.

The build process involves running npm, which will read the package.json
file and attempt to download and install any missing dependencies. That
introduces an impurity to the nix build, so buildNodePackage runs npm with
--registry example.com, which causes the download to fail with the sort of
error you encountered.

Once you've got a nix expression that properly supplies all the necessary
dependencies, npm will not attempt any downloads and the build will succeed.

Hope this helps,

Colin

On Mon, Mar 9, 2015 at 6:38 AM, Kirill Elagin kirela...@gmail.com wrote:

 I have a package (`pkgs.keybase-node-client` to be precise) which is
 generated by `nodePackages.buildNodePackage`. I want to install it from my
 local git repo.

 I have no idea how node stuff works in nixpkgs (and not in nixpkgs,
 actually), so I tried the obvious thing:

 
   packageOverrides = pkgs_: {
 keybase-node-client = lib.overrideDerivation pkgs_.keybase-node-client
   (drv: {
 src = fetchgit {
   url = /home/kirrun/proj/keybase/node-client;
   ...
 };
   });
   };
 

 but this gives me a super-weird error when I try to install it:

 
 replacing old ‘keybase-node-client-0.7.7’
 installing ‘keybase-node-client-0.7.7’
 these derivations will be built:
   /nix/store/qsdsxcvnmn6hxs4kpi2mymmplwjq5kig-keybase-node-client-0.7.7.drv
 building path(s)
 ‘/nix/store/16pd9zjj1dh9pc2lpij5p5xqji0b88ag-keybase-node-client-0.7.7’
 building
 /nix/store/16pd9zjj1dh9pc2lpij5p5xqji0b88ag-keybase-node-client-0.7.7
 unpacking sources
 unpacking source archive
 /nix/store/m33g6lw3dg6455bqfnshhn73rn8710yz-node-client-7888c0d
 source root is node-client-7888c0d
 patching sources
 configuring
 'node_modules/iced-coffee-script' -
 '/nix/store/jhqn9ph542b8fc8ig8akq22sphbpi2ff-iced-coffee-script-1.7.1-g/lib/node_modules/iced-coffee-script'
 ... (more lines like that) ...
 'node_modules/request' -
 '/nix/store/56b058k267wsf5nhb9n7cw89gi4l90km-node-request-2.30.0/lib/node_modules/request'
 building
 npm ERR! registry error parsing json
 npm ERR! SyntaxError: Unexpected token 
 npm ERR! !doctype html
 npm ERR! html
 npm ERR! head
 npm ERR! titleExample Domain/title
 npm ERR!
 npm ERR! meta charset=utf-8 /
 npm ERR! meta http-equiv=Content-type content=text/html;
 charset=utf-8 /
 npm ERR! meta name=viewport content=width=device-width,
 initial-scale=1 /
 npm ERR! style type=text/css
 ... (strip boring CSS) ...
 npm ERR! body
 npm ERR! div
 npm ERR! h1Example Domain/h1
 npm ERR! pThis domain is established to be used for illustrative
 examples in documents. You may use this
 npm ERR! domain in examples without prior coordination or asking for
 permission./p
 npm ERR! pa href=http://www.iana.org/domains/example;More
 information.../a/p
 npm ERR! /div
 npm ERR! /body
 npm ERR! /html
 npm ERR!
 npm ERR! at Object.parse (native)
 npm ERR! at RegClient.anonymous
 (/nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/lib/node_modules/npm/node_modules/npm-registry-client/lib/request.js:274:23)
 npm ERR! at Request._callback
 (/nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/lib/node_modules/npm/node_modules/npm-registry-client/lib/request.js:246:65)
 npm ERR! at Request.self.callback
 (/nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/lib/node_modules/npm/node_modules/request/request.js:236:22)
 npm ERR! at Request.emit (events.js:98:17)
 npm ERR! at Request.anonymous
 (/nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/lib/node_modules/npm/node_modules/request/request.js:1142:14)
 npm ERR! at Request.emit (events.js:117:20)
 npm ERR! at IncomingMessage.anonymous
 (/nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/lib/node_modules/npm/node_modules/request/request.js:1096:12)
 npm ERR! at IncomingMessage.emit (events.js:117:20)
 npm ERR! at _stream_readable.js:943:16
 npm ERR! If you need help, you may report this *entire* log,
 npm ERR! including the npm and node versions, at:
 npm ERR! http://github.com/npm/npm/issues

 npm ERR! System Linux 3.18.2-gentookirNote
 npm ERR! command
 /nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/bin/node
 /nix/store/liq47hvqy92ha47q123y0106pwv404j2-nodejs-0.10.33/bin/npm
 --registry http://www.example.com;
 --nodedir=/nix/store/5r47h9ipnlrpp05miaj6d3jzw9s7rdna-node-sources
 install
 /tmp/nix-build-keybase-node-client-0.7.7.drv-0/node-client-7888c0d
 npm ERR! cwd
 /tmp/nix-build-keybase-node-client-0.7.7.drv-0/node-client-7888c0d/build-dir
 npm ERR! node -v v0.10.33
 npm ERR! npm -v 1.4.28
 npm ERR! type unexpected_token
 npm ERR! not ok code 0
 builder for
 ‘/nix/store/qsdsxcvnmn6hxs4kpi2mymmplwjq5kig-keybase-node-client-0.7.7.drv’
 failed with exit code 1
 error: build of
 

Re: [Nix-dev] State database in nixops

[Colin Putney]

On Sat, Feb 21, 2015 at 4:06 PM, Thomas Hunger tehun...@gmail.com wrote:


 We also have a CI server which deploys for us, but that's not the same
 server as the common one we use for manual deploys (which are unfortunately
 necessary on occasion). So we have two copies of the state which has
 already caused some problems.


Could you expand on this a bit? I've been using nixops for a while, but
only recently set up a Hydra server to run tests automatically. I'm now
considering doing automated deployments out of hydra, but not quite sure
how that should work. It would be simple to have a hydra job that runs
nixops deploy but having a build with external side-effects like that
seems problematic.

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

Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))

[Colin Putney]

On Sun, Dec 28, 2014 at 11:11 PM, Ertugrul Söylemez ert...@gmx.de wrote:

 Hi Colin,

  This sounds a lot like Disnix! How would it be similar? How would it
  be different?

 Disnix and NixOps are machine-oriented.  You have a network of machines
 with configurations.  The goal is a service-oriented architecture.
 Every service itself is a machine, and those machines can be combined
 to larger machines.


Yeah, that's certainly true of Nixops. My understanding of Disnix, though,
is that it let's you describe, separately, services in the abstract,
machines available for running them, and the deployment of abstract
services onto the physical machines.

Disnix seems to be dead, though, so even if what you're proposing is very
similar, it would be a big improvement on the current state of the art.

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

Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))

[Colin Putney]

On Sun, Dec 28, 2014 at 11:13 AM, Ertugrul Söylemez ert...@gmx.de wrote:


  Instead a lot of services can be treated as a sequence of isolated
  containers, and a small set of load-balanced, mutable service entry
  points.  Namespace magic can make a lot of previously global state,
  local, such as ports, pid-files, log files etc.
 
  For these kinds of services, you don't need graceful shutdown, which is a
  great simplification, similarly to what docker typically provides.
 
  I feel that a great design in this area should blend well with
 distributing
  services across machines, failover, etc. which are concerns that systemd
  doesn't start to cover.

 That's a very good summary of why I want to implement my proposal.  Let
 me see if I can get a working prototype.


This sounds a lot like Disnix! How would it be similar? How would it be
different?

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

Re: [Nix-dev] [Ann] Sublime Text/TextMate/Atom syntax highlighter

[Colin Putney]

On Sun, Nov 30, 2014 at 5:01 PM, Wout Mertens wout.mert...@gmail.com
wrote:

 Hey all,

 I made a highlighter for Sublime Text, which uses the TextMate format.
 Atom also seems to use it, as does github.


This works nicely. Thanks!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Nixops errors

[Colin Putney]

Hi folks,

I'm wrestling with a problem that's causing my Nixops deployments to fail.
I'm getting a lot of messages on the console that look like this:

terminate called after throwing an instance of 'nix::Error'
error: unexpected end-of-file

The number of ssh connections to the target machine grows and eventually
the whole process just hangs. Any idea what might cause this?

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

[Nix-dev] SF meetup?

[Colin Putney]

Hi,

Is anybody using Nix in San Francisco? If so, I'd love to meet you! Let's
get together and compare notes.

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

Re: [Nix-dev] Reengineered npm2nix: call for feedback

[Colin Putney]

On Tue, Oct 21, 2014 at 1:17 PM, Sander van der Burg svanderb...@gmail.com
wrote:

 I think the problem with relative paths is solved now. Now the directory
 in which the package.json file resides is also taking into account in the
 generation process.

 I tested it against a simple custom-made testcase.


Thanks Sander!

I tested it against my more-complex use case and found a couple more
issues. I've submitted a pull request with fixes.

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

Re: [Nix-dev] Reengineered npm2nix: call for feedback

[Colin Putney]

On Tue, Sep 30, 2014 at 3:13 AM, Sander van der Burg svanderb...@gmail.com
wrote:


 I've used the reengineered npm2nix on a private project for the company I
 work for, as well as some other utilities and it seems to work fine for me.

 Hopefully, you can also try npm2nix on your projects to find out whether
 there any additional issues. :)

 Furthermore, I'm still working a blog post to rationalize all the stuff,
 which should give you better insights in the problem, details and the
 choices I made.

 Let me know what you think!


Hi Sander,

I've just tried out this version and I'm finding it pleasant improvement
over the old way. The generated code is clean and simple, and I like the
minimal dependency it has on nixpkgs.

However, there's one thing I haven't been able to get working: local path
dependencies.

I have several node apps that rely on a collection of node modules. These
modules may, in turn rely on other modules. In addition, both the apps and
the modules depend on modules from npm. My current setup involves
generating nix expressions using npm2nix (Sheay's version) to get the NPM
dependencies, then hand-editing the default.nix files for each app and
module, to pull in the additional dependencies that don't come from npm.

As of NPM 2.0, dependencies can be specified as paths on the local file
system, and I'd like to use that feature to generate nix expressions for
both local and npm dependencies using npm2nix. It almost works, but not
quite. AFAICT, the nix expressions are generated just fine, but then when
the derivation is being created, the relative paths are resolved against
the current directory of the of the process, rather than against the
directory that contains the package.json file. That causes the derivation
to fail with ENOENT.

All in all, looks like big improvement!

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

[Nix-dev] Bower2nix

[Colin Putney]

Hi folks,

I'm trying to use nix (and nixops) to deploy a web app. It includes some
client-side components from bower. I've used bower2nix to generate some
nix-expresssions for downloading the bower packages, but I can't quite see
how to incorporate them into the derivation for my app.

What I'd like to do is generate symlinks to these components during the
built—that is, copy my app's files into $out and then create a directory
called bower_components containing links into the nix-store.

However, the nix expressions generated by bower2nix evaluate to a
user-environment derivation. This is *sort* what I'm looking for—a
directory of links in to the nix store—but if I just create a link to the
environment in my app, the app has to use some pretty gorky paths
(containing hashes and version numbers) to serve up the bower components.

So, what am I missing? How was bower2nix intended to be used?

Thanks,

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

Re: [Nix-dev] Anyone care to review my post on the Nix expression language?

[Colin Putney]

On Wed, Oct 8, 2014 at 5:00 AM, James Harrison Fisher 
jameshfis...@gmail.com wrote:

 Thanks Ellis! If there’s anything you didn’t enjoy, I’d love to know,
 since I’ll be writing more of these and I want to establish a style that
 people like. :-)


Awesome article.  I especially liked the gory detail on how expression
trees are evaluated. I've been writing nix expressions for a few months and
already knew most of the material you covered, but that section really made
it clear how and why lazy evaluation works the way it does.

The only thing I didn't enjoy was the I lied motif. Especially after the
lazy-lists thing, it made me wonder if I could believe what I was a
reading. The general technique of over-simplifying and then introducing
layers of nuance is good, but I think you over-did it.

I'm really looking forward to the next article!

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

Re: [Nix-dev] Infinite recursion with npm2nix

[Colin Putney]

On Tue, Apr 15, 2014 at 8:27 AM, Shea Levy s...@shealevy.com wrote:

 Hi Colin,

 I've added pure-0.5.0-rc-1 to nixpkgs, can you try using that as a
 dependency?


Hi Shea,

Thanks for looking into this. Unfortunately, I don't think this approach is
the right  way to go.

Pure is a CSS framework; it provides CSS files, not Javascript. It's source
tree doesn't contain production-ready CSS; that has to be built from
snippets of CSS in the source tree. The build is implemented using Grunt
and a bunch of npm packages for processing CSS. My attempt at packaging
Pure was more-or-less like a classical C-based package: download the
source, compile, then install the resulting CSS into the store. The version
currently in nixpkgs just installs the source code; to get useful CSS it
needs to be built.

I notice that nixpkgs doesn't currently include any npm packages with peer
dependencies. Is this because of the infinite recursion? I couldn't tell if
it's a problem inherent to the current implementation of npm2nix, or just
an artifact of the way I'm using it.

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

Re: [Nix-dev] Infinite recursion with npm2nix

[Colin Putney]

On Wed, Apr 16, 2014 at 9:33 AM, Shea Levy s...@shealevy.com wrote:


 Hmm, yes we do, for example
 nodePackages.by-version.grunt-contrib-cssmin.0.9.0. Are you by any
 chance using the 13.10 branch of nixpkgs? It's entirely possible the
 buildNodePackage there doesn't work properly with peerDependencies.


I've been using the unstable channel. I'll try again with HEAD.

Thanks,

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

[Nix-dev] Nixos.org down

[Colin Putney]

Hope this right place to post this. I don't speak German, but it looks like
the domain is being blocked, for some reason.


*Diese Domain wurde gesperrt...*

Falls Sie der Administrator dieser Domain
sind und Fragen zur Sperrung Ihrer
Domain haben, wenden Sie sich bitte
an unser Support-Team http://www.united-domains.de/support/.


Cheers,

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

[Nix-dev] Infinite recursion with npm2nix

[Colin Putney]

Hi folks,

In my on-going quest to package up my node applications, I've run into a
noob-trap that has me completely stumped.

The app is a web app, so it has both client- and server-side code. One of
the dependencies is Yahoo's Pure CSS library. PureCSS, in turn relies on
Grunt for its build process. I've created the following nix expressions:

$ cat purecss.nix
{ pkgs ? import nixpkgs {} }:

with pkgs.stdenv.lib;

let

  name = pure-css;
  version = v0.5.0-rc-1;

  # pull in the code for building npm packages
  nodePackages = import ./purecss-npm-packages.nix {
inherit pkgs;
inherit (pkgs) stdenv nodejs fetchurl fetchgit;
neededNatives = [ pkgs.python ] ++ pkgs.lib.optional
pkgs.stdenv.isLinux pkgs.utillinux;
self = nodePackages;
  };

  buildModules = [
 nodePackages.bower
 nodePackages.grunt
 nodePackages.grunt-cli
 nodePackages.grunt-contrib-cssmin
 nodePackages.grunt-contrib-clean
 nodePackages.grunt-contrib-copy
 nodePackages.grunt-contrib-concat
 nodePackages.grunt-contrib-compress
 nodePackages.grunt-contrib-csslint
 nodePackages.grunt-contrib-watch
 nodePackages.grunt-css-selectors
 nodePackages.grunt-pure-grids
 nodePackages.grunt-stripmq
  ];

in pkgs.stdenv.mkDerivation {

  name = ${name}-${version};

  src = pkgs.fetchgit {
url = https://github.com/yui/pure;
rev = refs/tags/v0.5.0-rc-1;
sha256 =
049ac2ef812771852978d11cd5aecac2dd561e97bb16ad89c79eb1e10aa57672;
  };

  buildInputs = buildModules;

  buildCommand = ''
cp -r $src src
chmod +w src
cd src
grunt
  '';

}


$ cat purecss-npm-packages.nix
{ pkgs, stdenv, nodejs, fetchurl, fetchgit, neededNatives, self }:

rec {

  nativeDeps = {};

  buildNodePackage = import
${pkgs.path}/pkgs/development/web/nodejs/build-node-package.nix {
inherit stdenv nodejs neededNatives;
inherit (pkgs) runCommand;
  };

  patchSource = fn: srcAttrs:
let src = fn srcAttrs; in pkgs.runCommand src.name {} ''
  mkdir unpack
  cd unpack
  unpackFile ${src}
  chmod -R +w */
  mv */ package 2/dev/null || true
  sed -i -e s/:\s*\latest\/:  \*\/ -e
s/:\s*\\(https\?\|git\(\+\(ssh\|http\|https\)\)\?\):\/\/[^\]*\/:
\*\/ package/package.json
  mv */ $out
'';

  # Backwards compat
  patchLatest = patchSource fetchurl;

} // import ./purecss-npm-generated.nix { inherit self fetchurl fetchgit;
inherit (pkgs) lib; }


The file purecss-npm-generated.nix is about 4000 lines of nix expressions
generated by npm2nix.



Now, the problem is this:

error: while evaluating the attribute `nativeBuildInputs' of the derivation
`pure-css-v0.5.0-rc-1' at
/Users/colin/Better/usul/edric/harah/purecss.nix:36:3:
while evaluating the attribute `deps' of the derivation
`node-grunt-css-selectors-1.0.0' at
/Users/colin/Better/usul/edric/harah/purecss-npm-generated.nix:1807:5:
while evaluating the attribute `deps' of the derivation
`node-rework-0.20.2' at
/Users/colin/Better/usul/edric/harah/purecss-npm-generated.nix:3389:5:
while evaluating the attribute `nativeBuildInputs' of the derivation
`node-rework-inherit-0.2.1' at
/Users/colin/Better/usul/edric/harah/purecss-npm-generated.nix:3426:5:
infinite recursion encountered


The relevant section of the generated code is here:


  by-spec.rework.= 0.15.0 =
self.by-version.rework.0.20.2;
  by-version.rework.0.20.2 = lib.makeOverridable self.buildNodePackage {
name = node-rework-0.20.2;
src = [
  (fetchurl {
url = http://registry.npmjs.org/rework/-/rework-0.20.2.tgz;;
name = rework-0.20.2.tgz;
sha1 = b64b082a1660cf33c874729353ead5341c100d23;
  })
];
buildInputs =
  (self.nativeDeps.rework or []);
deps = [
  self.by-version.css.1.6.0
  self.by-version.commander.1.0.4
  self.by-version.color-parser.0.1.0
  self.by-version.hsb2rgb.1.0.2
  self.by-version.mime.1.2.11
  self.by-version.debug.0.8.0
  self.by-version.rework-inherit.0.2.1
  self.by-version.rework-visit.1.0.0
  self.by-version.convert-source-map.0.3.3
  self.by-version.rework.0.20.2
];
peerDependencies = [
];
passthru.names = [ rework ];
  };
  by-spec.rework.=0.18.0 =
self.by-version.rework.0.20.2;
  by-spec.rework.=0.20.2-0 0.21.0-0 =
self.by-version.rework.0.20.2;
  by-spec.rework.=0.20.2-0 =0.20.2-0 0.21.0-0 =
self.by-version.rework.0.20.2;
  by-spec.rework.~0.20.2 =
self.by-version.rework.0.20.2;
  by-spec.rework-inherit.0.2.1 =
self.by-version.rework-inherit.0.2.1;
  by-version.rework-inherit.0.2.1 = lib.makeOverridable
self.buildNodePackage {
name = node-rework-inherit-0.2.1;
src = [
  (fetchurl {
url = 
http://registry.npmjs.org/rework-inherit/-/rework-inherit-0.2.1.tgz;;
name = rework-inherit-0.2.1.tgz;
sha1 = fdd01a199b0a86ef909436fb373f7b343936f185;
  })
];
buildInputs =
  (self.nativeDeps.rework-inherit or []);
deps = [
  self.by-version.debug.0.8.0
  

Re: [Nix-dev] Maven support in nix

[Colin Putney]

On Mon, Apr 7, 2014 at 1:25 AM, Marc Weber marco-owe...@gmx.de wrote:


 Existing solutions (non Java):
 - cabal2nix (cabal descriptions to nix)
 - py2nix (or such) same for python
 - ruby2nix (or such ) same for ruby

 -hacknix/nixpkgs-ruby-overlay (they convert hackage/rubyforge to a pool
 which gets translated to .nix files, derivations get created by
 functions on the fly)


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

[Nix-dev] stripHash

[Colin Putney]

Hi all,

The Nixpkgs Manual mentions that stdenv provides a shell function,
stripHash, that will strip off the directory and hash part of a store path,
and print out just the name. (See
http://nixos.org/nixpkgs/manual/#fun-stripHash).

However, it doesn't actually print anything out. (At least not in my
environment--nixpkgs from the unstable channel, recently updated). Digging
further:

[nix-shell:/tmp/build]$ type stripHash
stripHash is a function
stripHash ()
{
strippedName=$(basename $1);
if echo $strippedName | grep -q '^[a-z0-9]\{32\}-'; then
strippedName=$(echo $strippedName | cut -c34-);
fi
}

It seems that it's correctly stripping off the name, but not echoing it as
the manual suggests. And sure enough, poking around in builder scripts in
nixpkgs, there are lots of uses of stripHash that follow this pattern:

$(stripHash $foo; echo $strippedName)

Is this a bug that everybody just works around, or is it the desired
behaviour?

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

Re: [Nix-dev] Nixops on headless server

[Colin Putney]

On Wed, Apr 2, 2014 at 6:40 AM, Marco Maggesi magg...@math.unifi.it wrote:

 Hi, there seems to be again a problem with nixops with virtualbox headless
 nodes.

 $ nixops deploy -d minicloud
 webserver creating VirtualBox VM...
 webserver Virtual machine
 'nixops-24856f59-ba5b-11e3-a2e6-2d15dd5fa0ff-webserver' is created and
 registered.
 webserver UUID: d6ea884c-3173-4e12-bada-aeff1112c39c
 webserver Settings file: '/home/maggesi/VirtualBox
 VMs/nixops-24856f59-ba5b-11e3-a2e6-2d15dd5fa0ff-webserver/nixops-24856f59-ba5b-11e3-a2e6-2d15dd5fa0ff-webserver.vbox'
 webserver creating disk 'disk1'...
 webserver 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
 webserver Clone hard disk created in format 'VDI'. UUID:
 ad027933-92f8-4655-8f63-a3bf582122b8
 webserver attaching disk 'disk1'...
 webserver VBoxManage: error: The virtual machine
 'nixops-24856f59-ba5b-11e3-a2e6-2d15dd5fa0ff-webserver' has terminated
 unexpectedly during startup with exit code 1
 webserver VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005),
 component Machine, interface IMachine
 webserver Waiting for VM
 nixops-24856f59-ba5b-11e3-a2e6-2d15dd5fa0ff-webserver to power on...
 webserver waiting for IP address...

 Can you test and confirm the problem.


Works fine for me. This looks like a problem with VirtualBox, not nix.

According to https://www.virtualbox.org/ticket/7367,

it's that you don't have a GUI available, so VirtualBox can't open a window
for the console.

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

[Nix-dev] Variable data files

[Colin Putney]

Hi folks,

I'm packaging an app that I'd like to deploy on NixOS, and trying to figure
out how to handle data files that the app needs to be able to write to. So
here some newbie questions:

1) Is there a standard place for application installed in the nix store to
use for variable data?

2) Is there a standard place for application logs?

3) I'm going to be deploying with nixops. What's the best way to handle
creating these directories setting ownership and permissions etc.

Thanks,

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

Re: [Nix-dev] NiJS package manager

[Colin Putney]

On Tue, Apr 1, 2014 at 4:52 PM, Sander van der Burg - EWI 
s.vanderb...@tudelft.nl wrote:


 I have decided to update my blog post with some additional notes based on
 the discussion:


Ugh. I fell for it. I even wondered if it could be a joke and then decided
No way! Look at all this code. Documentation! The guys been working on
this for 18 months!

Well played.

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

Re: [Nix-dev] NiJS package manager

[Colin Putney]

On Tue, Apr 1, 2014 at 6:18 AM, Shell Turner cam.t...@gmail.com wrote:

 
 http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html

  I have discovered that the Nix expression language is complicated and
  difficult to learn. Like Haskell, it has a solid theoretical foundation
  and powerful features (such as laziness), but it's too hard to learn by
  developers without an academic background.

 I entirely disagree with this. From my perspective, Nix is a great
 language which covers the simple cases simply.


Me too.

Ditching Nix would be a disaster for the NixOS ecosystem. Here's why:

1) It's a lot of work. The NixOS has some momentum, and a decision to
deprecate Nix and rewrite everything in NiJS would stall that momentum.
Lots of effort would go into reimplementing stuff that already works fine,
and dealing with interoperability problems between legacy Nix expressions
and newly-written NiJS code. During the transition period, it would create
confusion for newbies and cause the whole system to be more difficult to
understand, even for experts.

2) The main barrier to adoption isn't Nix syntax anyway. It's inertia.
NixOs is fighting over 40 years of tradition in the Unix community. There
have been pitched battles about whether /usr should be mounted read-only,
whether 3rd-party software should go in /usr/local or /opt/local, and
whether binaries run by other processes should be in /usr/bin or
/usr/libexec. For people steeped in the details of the Linux Filesystem
Hierarchy Standard, something like the nix store is completely alien. Every
time Nix comes up in a public forum (Reddit, Hacker News, mailing lists)
there's a hundred comments that boil down to you don't understand how
packaging works. For every person who's thrilled by the idea of a
purely-functional package manager, there's a thousand who think apt-get is
so easy! and can't even imagine that something better is possible.
Switching to Javascript as the packaging language won't solve any of those
problems.

3) Asynchronous programming is hard. Sure, there are a lot of Javascript
programmers out there, who will have some experience with callbacks. For
everybody else, callbacks are a pain in the ass. They make it hard to
reason about flow control, which makes everything else harder, especially
error handling and debugging. Javascript may be more mainstream than Nix,
but for a lot of people, it won't be easier to learn.

4) Switching to node may attract Javascript programmers, but it will repel
people in other communities. If Nix comes to be seen as a Node thing it
will cause people to ignore it just because they're using some other
language. It might even cause people to start making clones for their
languages--think Rubix and PyNix--so they integrate better with their
ecosystem. (See, for example, Make, Rake, Grunt and Fabric.) Because it's a
domain-specific language, Nix expressions don't have to come down on one
side or the other in the language wars and can play nicely with everybody.

5) Switching from Nix to NiSJ goes against trend. Node is popular, sure,
but it doesn't completely dominate programming the way Java did in the 90s,
and it never will. There's probably still some growth left in the Node
ecosystem, but not orders of magnitude more. On the other hand, functional
languages have their best years ahead of them. Clojure, Erlang, Scala and
Haskell are all growing steadily, and functional languages are seen as the
future, even if they're not dominant today. The cool kids have switched
from Ruby to Node in the last few years, but it won't be too many years
before they switch to something else, and it's likely to be a functional
language.

6) As languages go, Nix is actually quite practical and approachable.
There's no compile step, and no type system to form initial barriers to
entry. Nix files tend to be short and consist mostly of attribute sets,
which have a very obvious syntax. It's easy to copy-and-modify a nix
expression if you only need to make minor tweaks. This is exactly the kind
of approachability and simple-to-get-started feel that made PHP so popular,
but Nix has much more elegant underpinnings.

So please, keep the faith! Nix is solid. There's no need to switch to
something else.

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