Re: [Nix-dev] Using Nix as the preferred package manager for a new language

[Roger Qiu]

There's some work on Nix on Windows:

* https://nixos.org/wiki/Nix_on_Windows
* https://ternaris.com/lab/nix-on-windows.html

On 13/02/2016 12:01 AM, Philipp Hausmann wrote:

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.



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


--
Founder of Matrix AI
https://matrix.ai/
+61420925975

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

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[Roger Qiu]

Hey Gleb,

Thanks for the explanation. That makes sense, although I'm thinking of 
scalability, in terms of when other languages come around to Nix. Having 
all that in nixpkgs might make it quite bloated.


However the problem with cross channel dependencies is an interesting 
one, I suppose this problem needs to be fixed first.


Thanks,
Roger

On 15/02/2016 5:10 PM, Gleb Peregud wrote:


Hey Roger

Adding Eric, since he did a lot of work here too.

Few things. I'd like Erlang packages to be integrated into nixpkgs, so 
that they can have native dependencies. There's no package manager out 
there for Erlang which both has good coverage for Erlang packages and 
supports specifying native dependencies. Won't putting them into 
separate channel make it harder to do the latter? This is my first Nix 
project, so I'm not yet fully familiar with it.


For now it was not a problem to get things merged into nixpkgs, so I 
have nothing to complain here. There are indeed few Erlang users in 
Nix community, so I was getting some help. Existing infrastructure did 
help finding some falling builds, so it's also useful.


As you can see, currently all Erlang but one packages in nixpkgs are 
taken from hex.pm  as this seem to be the most mature 
centralized package repo for Erlang. It also provides APIs which are 
handy to use in hex2nix conversion tool.


Cheers,
Gleb

On Feb 15, 2016 6:58 AM, "Roger Qiu" > wrote:


Hey Gleb,

Was curious about this, why put erlang packages into the main
nixpkgs repo, and in a separate channel?

The advantages could be that you don't have to wait on nixpkgs to
accept changes to erlang packages.

On the otherhand, maybe it's to take advantage of the CI and hydra
and a concentrated community?

Thanks,
Roger

On 15/02/2016 3:37 AM, Gleb Peregud wrote:


Ah, missed this email before. Just wanted to point out that large
chunk of this support was implemented by Eric B. Merritt, so at
least half of kudos goes to him.

Cheers
Gleb

On Feb 13, 2016 18:20, "stewart mackenzie" mailto:setor...@gmail.com>> wrote:

Tristan, Gleb Peregud has implemented first class support for
Erlang
in Nix, pleas read the docs:

http://hydra.nixos.org/build/31821726/download/1/nixpkgs/manual.html#users-guide-to-the-erlang-infrastructure

/sjm
___
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


-- 
Founder of Matrix AI

https://matrix.ai/
+61420925975 



--
Founder of Matrix AI
https://matrix.ai/
+61420925975

___
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

[zimbatm]

Sorry if I'm re-digging an old bone. Is the consensus really to kill the
wiki or is it just because it's in a bad state ? It still seems like it's
holding valuable information and can also serve as a staging area after
some cleanup.

Anyways if there is no interest, no worries, I'll just be contributing in
some other ways :)

On Sun, 14 Feb 2016 at 21:19 Arseniy Seroka  wrote:

> There was a huge discussion about wiki's future [1].
>
> [1] http://lists.science.uu.nl/pipermail/nix-dev/2015-November/018645.html
>
> 2016-02-15 0:15 GMT+03:00 zimbatm :
>
>> Thanks Eelco !
>>
>> Check this out: http://nixos-wiki-test.zimbatm.com/Main_Page/
>>
>> It's a conversion to Markdown, a Jekyll template with the nixos-homepage
>> css, all hosted on github. The idea is that people can still edit the wiki
>> but have to submit a PR to introduce changes. It's a bit more work for us
>> but it also means that we can keep the spammers at bay and monitor the
>> quality of the submissions.
>>
>> Obviously it's not perfect, this is just a prototype. There are issues
>> with the links, navigation and some pages are missing. There also questions
>> as how to integrate with the rest of nixos.org.
>>
>> The nice thing about that approach is that we can re-run the import any
>> time until it's ready.
>> But before I invest more time, do you think it's a path worth pursuing ?
>> Also what would be required for this to be considered "ready" ?
>>
>> Link to repo: https://github.com/zimbatm/nixos-wiki-test/
>>
>>
>> On Fri, 12 Feb 2016 at 14:26 Eelco Dolstra 
>> wrote:
>>
>>> 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
>>
>>
>
>
> --
> Sincerely,
> Arseniy Seroka
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Understanding configFile usage

[Brandon Barker]

Hi,

I've been trying to get a NixOS  image working on our Eucalyptus cloud. It
looks like cloud-init.nix (

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/system/cloud-init.nix

) has a reasonable default for our purposes (permits root login, etc).
However, after I look at the actual cloud.cfg file under /nix/store, it
appears to be different - a heavily commented file that is probably the
default shipped with cloud-init (root login is disabled, etc.).

Is there a way I could quickly get the appropriate behavior using my
configuration.nix file? I suppose the best way to do this would be to model
all the options in the cloud-init.nix, but I'd like to get it actually on
our cloud first so I can start experimenting more with nix for actual work
:).



-- 
Brandon E. Barker
http://www.cac.cornell.edu/barker/
___
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

[Arseniy Seroka]

There was a huge discussion about wiki's future [1].

[1] http://lists.science.uu.nl/pipermail/nix-dev/2015-November/018645.html

2016-02-15 0:15 GMT+03:00 zimbatm :

> Thanks Eelco !
>
> Check this out: http://nixos-wiki-test.zimbatm.com/Main_Page/
>
> It's a conversion to Markdown, a Jekyll template with the nixos-homepage
> css, all hosted on github. The idea is that people can still edit the wiki
> but have to submit a PR to introduce changes. It's a bit more work for us
> but it also means that we can keep the spammers at bay and monitor the
> quality of the submissions.
>
> Obviously it's not perfect, this is just a prototype. There are issues
> with the links, navigation and some pages are missing. There also questions
> as how to integrate with the rest of nixos.org.
>
> The nice thing about that approach is that we can re-run the import any
> time until it's ready.
> But before I invest more time, do you think it's a path worth pursuing ?
> Also what would be required for this to be considered "ready" ?
>
> Link to repo: https://github.com/zimbatm/nixos-wiki-test/
>
>
> On Fri, 12 Feb 2016 at 14:26 Eelco Dolstra 
> wrote:
>
>> 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
>
>


-- 
Sincerely,
Arseniy Seroka
___
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

[zimbatm]

Thanks Eelco !

Check this out: http://nixos-wiki-test.zimbatm.com/Main_Page/

It's a conversion to Markdown, a Jekyll template with the nixos-homepage
css, all hosted on github. The idea is that people can still edit the wiki
but have to submit a PR to introduce changes. It's a bit more work for us
but it also means that we can keep the spammers at bay and monitor the
quality of the submissions.

Obviously it's not perfect, this is just a prototype. There are issues with
the links, navigation and some pages are missing. There also questions as
how to integrate with the rest of nixos.org.

The nice thing about that approach is that we can re-run the import any
time until it's ready.
But before I invest more time, do you think it's a path worth pursuing ?
Also what would be required for this to be considered "ready" ?

Link to repo: https://github.com/zimbatm/nixos-wiki-test/


On Fri, 12 Feb 2016 at 14:26 Eelco Dolstra 
wrote:

> 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] Travis Testing Needs Rethinking

[Arseniy Seroka]

There are several things we need to check in a PR even if it builds
successfully.
On 14 Feb 2016 21:44, "zimbatm"  wrote:

> What if master was always the latest successful hydra build ? People could
> rebase on top and have cached builds. Nox could also have cached builds.
>
> Instead of merging a PR we would instruct Hydra to queue the build. If the
> build is successful hydra would merge it into master and close the PR.
> Otherwise it would amend the PR with the build errors. To instruct Hydra we
> could annotate a PR with a custom message like: "hydra go!".
>
> I believe that this would also help to spot regressions faster. Right now
> Darwin tends to get breaking chances because Nox only tests against Nixos.
> And since the builds would be done against all OSes we would also be able
> to merge all the unstable channels.
>
>
> On Sat, 13 Feb 2016 at 19:24 Kevin Cox  wrote:
>
>> On Sat, 2016-02-13 at 17:03 +, Adam Russell wrote:
>>
>> Wouldn't this all be less of an issue if the build on Hydra wasn't behind
>> by weeks? Should we talk about how to improve that? Personally I don't even
>> know how to navigate or interpret Hydra when I go look at it.
>>
>>
>> I don't think Hydra is actually behind much, the channels are but IIUC
>> most builds are actually completing in a couple of hours. (Actually looking
>> now I see some 2 day old builds but nothing too terrible
>> http://hydra.nixos.org/status).
>>
>> Getting faster hydra builds might make this less of an issue but there
>> will always be a delay. Of course if that delay is very small it won't
>> matter much.
>>
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Travis Testing Needs Rethinking

[zimbatm]

What if master was always the latest successful hydra build ? People could
rebase on top and have cached builds. Nox could also have cached builds.

Instead of merging a PR we would instruct Hydra to queue the build. If the
build is successful hydra would merge it into master and close the PR.
Otherwise it would amend the PR with the build errors. To instruct Hydra we
could annotate a PR with a custom message like: "hydra go!".

I believe that this would also help to spot regressions faster. Right now
Darwin tends to get breaking chances because Nox only tests against Nixos.
And since the builds would be done against all OSes we would also be able
to merge all the unstable channels.


On Sat, 13 Feb 2016 at 19:24 Kevin Cox  wrote:

> On Sat, 2016-02-13 at 17:03 +, Adam Russell wrote:
>
> Wouldn't this all be less of an issue if the build on Hydra wasn't behind
> by weeks? Should we talk about how to improve that? Personally I don't even
> know how to navigate or interpret Hydra when I go look at it.
>
>
> I don't think Hydra is actually behind much, the channels are but IIUC
> most builds are actually completing in a couple of hours. (Actually looking
> now I see some 2 day old builds but nothing too terrible
> http://hydra.nixos.org/status).
>
> Getting faster hydra builds might make this less of an issue but there
> will always be a delay. Of course if that delay is very small it won't
> matter much.
>
> ___
> 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] [erlang-questions] Erlang Package Manager

[Gleb Peregud]

Ah, missed this email before. Just wanted to point out that large chunk of
this support was implemented by Eric B. Merritt, so at least half of kudos
goes to him.

Cheers
Gleb
On Feb 13, 2016 18:20, "stewart mackenzie"  wrote:

> Tristan, Gleb Peregud has implemented first class support for Erlang
> in Nix, pleas read the docs:
>
> http://hydra.nixos.org/build/31821726/download/1/nixpkgs/manual.html#users-guide-to-the-erlang-infrastructure
>
> /sjm
> ___
> 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] Haskell Infrastructure - Nix-Shell with Hoogle from cabal2nix

[Andreas Herrmann]

Hi,

I'm trying to understand how to use the Haskell-infrastructure properly.

Suppose I have an existing Haskell project with the following cabal file:

test.cabal
~~~
name:test
version: 0.1.0.0
license: BSD3
license-file:LICENSE
build-type:  Simple
cabal-version:   >=1.10

executable test
  main-is: Main.hs
  build-depends:   base, bytestring
  default-language:Haskell2010
~~~

I can use `cabal2nix` to generate a Nix derivation for it. The tool produces
the following file:

default.nix
~~~
{ mkDerivation, base, bytestring, stdenv }:
mkDerivation {
  pname = "test";
  version = "0.1.0.0";
  src = ./.;
  isLibrary = false;
  isExecutable = true;
  executableHaskellDepends = [ base bytestring ];
  license = stdenv.lib.licenses.bsd3;
}
~~~

And in order to build that package I can create the following Nix file:

pkg.nix
~~~
{ nixpkgs ? import  { }, compiler ? "default" }:
let
  inherit (nixpkgs) pkgs;
  haskellPackages = if compiler == "default"
then pkgs.haskellPackages
else pkgs.haskell.packages.${compiler};
in
haskellPackages.callPackage ./. { }
~~~

And then build the package with `nix-build ./pkg.nix`.

In order to create a development environment, where I have `cabal-install`
available as well, I can write the following Nix file:

shell.nix
~~~
{ nixpkgs ? import  { }, compiler ? "default" }:
let
  inherit (nixpkgs) pkgs;
  haskellPackages = if compiler == "default"
then pkgs.haskellPackages
else pkgs.haskell.packages.${compiler};
  inherit (pkgs.haskell.lib) addBuildTools;
  pkg = import ./pkg.nix { inherit nixpkgs compiler; };
in
(addBuildTools pkg (with haskellPackages; [ cabal-install ])).env
~~~


# My Question

How could I instead get a development environment with a Hoogle package
database of all the dependencies. I know that I could manually create the
following Nix file and use it with `nix-shell ./shell-manual.nix`.

shell-manual.nix
~~~
{ nixpkgs ? import  { }, compiler ? "default" }:
let
  inherit (nixpkgs) pkgs;
  haskellPackages = if compiler == "default"
then pkgs.haskellPackages
else pkgs.haskell.packages.${compiler};
  ghc = haskellPackages.ghcWithHoogle (pkgs: with pkgs; [
  base bytestring cabal-install
]);
in
pkgs.stdenv.mkDerivation {
  name = "dummy";
  buildInputs = [ ghc ];
  shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";
}
~~~

However, then I would have to manually maintain an extra dependency list. Is
there any way of transforming the Nix-Shell environment produced by `pkg.env`
in `shell.nix` above into one that adds a Hoogle database of all the included
packages?

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