Re: [Nix-dev] haskell structure for all of nixpkgs
Understood. The comments regarding name finding in this post are interesting: http://www.tweag.io/blog/stack-nix-portable-reproducible-builds seems like a common issue. (a lot of weight just to support incremental recompilation for Haskell!) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
I am not arguing against that kind of categorization at all. Its just that it only works where you have a directory structure. The Haskell approach does not, so it wont work there. Its a problem with the Haskell approach. Sent from [ProtonMail](https://protonmail.com), encrypted email based in Switzerland. Original Message Subject: Re: [Nix-dev] haskell structure for all of nixpkgs Local Time: April 25, 2016 12:49 PM UTC Time: April 25, 2016 7:49 PM From: setor...@gmail.com To: e...@merritt.tech CC: do...@dev.si,nix-dev@lists.science.uu.nl Ah I see, Haskell grepping is quite useless. Categorization using hierarchy generally is a good idea and makes sense for large amounts of information. This naturally ties in with a folder hierarchy. I personally find it refreshing information is stored in the directory structure aka the hierarchy. It also allows making little stateless expressions that can be copied and pasted around, they are intelligent enough to look at the folder structure and derive meaning. This helps when refactoring the hierarchy.___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
Ah I see, Haskell grepping is quite useless. Categorization using hierarchy generally is a good idea and makes sense for large amounts of information. This naturally ties in with a folder hierarchy. I personally find it refreshing information is stored in the directory structure aka the hierarchy. It also allows making little stateless expressions that can be copied and pasted around, they are intelligent enough to look at the folder structure and derive meaning. This helps when refactoring the hierarchy. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
Stewart, As I was formulating a reply, I think this crystallized for me. At the moment Nix encodes a lot of information in the file system/directory structure. Grep naturally surfaces that information. Due to this, In the haskell packages that information doesn't exist and so is not surfaceable, regardless of the command used. The easiest way to demonstrate this is to go into the root of your nixpkgs repo do the following: $> grep -r bytestring ./ Then in the same place do $> grep -r lwt ./ Notice the difference in comprehensibility and usefulness of the output .The first search is for a haskell package, the second and ocaml package. Arguably, I would say that that information shouldn't be encoded in the directory structure, it should be somewhere in the nix expression. If there was a nix command that was expression aware and allowed me to do the 'bytestring' search and get useful output like I get when I search for 'lwt', that would be very useful. Eric Original Message Subject: Re: [Nix-dev] haskell structure for all of nixpkgs Local Time: April 25, 2016 11:54 AM UTC Time: April 25, 2016 6:54 PM From: setor...@gmail.com To: e...@merritt.tech CC: do...@dev.si,nix-dev@lists.science.uu.nl I see, What would that tooling look like? Can anyone else see any other drawbacks of this approach? How do Haskellers deal with searching for packages?___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
Stewert, I did the majority of the Erlang/Beam packaging and I followed the Haskell model for two main reasons. 1. It worked so well in Haskell - why deviate? 2. Expression generation was much easier. I think these strongly win out, at at least for the Erlang/Beam world. The downside is that grepping the nixpkgs repository (my default way to search for a package) doesn't work nearly as well. My suspicion is that, if you wanted to go this route generally, you would need to improve the tooling around searching for packages/expressions. Eric Original Message Subject: Re: [Nix-dev] haskell structure for all of nixpkgs Local Time: April 25, 2016 11:15 AM UTC Time: April 25, 2016 6:15 PM From: setor...@gmail.com To: john_eric...@brown.edu CC: nix-dev@lists.science.uu.nl On Tue, Apr 26, 2016 at 2:02 AM, Ericson, John wrote: > I'd say https://github.com/NixOS/nixpkgs/pull/14000 was the first big step > in this direction, and hopefully > https://github.com/NixOS/nixpkgs/issues/10874 will lead to the second. Thanks John for the links, fantastic stuff. ___ 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] haskell structure for all of nixpkgs
I see, What would that tooling look like? Can anyone else see any other drawbacks of this approach? How do Haskellers deal with searching for packages? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
On Tue, Apr 26, 2016 at 2:02 AM, Ericson, John wrote: > I'd say https://github.com/NixOS/nixpkgs/pull/14000 was the first big step > in this direction, and hopefully > https://github.com/NixOS/nixpkgs/issues/10874 will lead to the second. Thanks John for the links, fantastic stuff. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
Well, besides working on other langauges' integration, I think there are some Petisms™ that all of nixpkgs could benefit from. A good example is pervasive use of `self: super: ...` and fix+extend rather than ad-hoc hacks and the scary reflection used in `lib/customization.nix`. I'd say https://github.com/NixOS/nixpkgs/pull/14000 was the first big step in this direction, and hopefully https://github.com/NixOS/nixpkgs/issues/10874 will lead to the second. On Mon, Apr 25, 2016 at 10:26 AM, stewart mackenzie wrote: > Okay Domen's a +1, maybe the guys and girls who implemented haskell > like PL level package systems could weigh in with insight. For example > ICIUC, Erlang packages adopts the same approach. The gained knowledge > could be helpful to start with this document. > > Could someone with experience please write, in this thread, a few > words about this approach? Keep it small and simple. > > Hopefully this gets more people interested by understanding it. Domen > says it's advanced and simple... why is it advanced and simple? > ___ > 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] [JOB] Fullstack web developer
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] haskell structure for all of nixpkgs
Okay Domen's a +1, maybe the guys and girls who implemented haskell like PL level package systems could weigh in with insight. For example ICIUC, Erlang packages adopts the same approach. The gained knowledge could be helpful to start with this document. Could someone with experience please write, in this thread, a few words about this approach? Keep it small and simple. Hopefully this gets more people interested by understanding it. Domen says it's advanced and simple... why is it advanced and simple? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
I agree - someone should start a tutorial how new language support is added and the infrastructure should be based on Haskell as it's most advanced and yet simple. On Mon, Apr 25, 2016 at 10:47 AM, stewart mackenzie wrote: > Hi Tomasz, > > On Sun, Apr 24, 2016 at 6:12 PM, Tomasz Czyż > wrote: > > do you have any description of what you are exactly talking about? > > Adopting this approach brings a huge amount of flexibility, could be > that this style of structuring can be rolled out for different > languages. Sure there are differences in how languages publish > packages, but it could be Peter's solution is a 80% solution > applicable to most languages. > > This approach might mean if nixers want support for a new language > they could plug into this this rather advanced packaging structure and > hopefully it works out well. Existing supported languages on Nix could > start converging onto this style of packaging. > > The current setup is each language has their own ad hoc solution for > getting packages, these packages are tightly bound. > So in the current setup, callPackage refers to a specific file, > whereas in the haskell setup the callPackage refers to a specific > recursive set of expressions that are self contained. > The package set is a function which produces a package set. This > function takes an argument which produces a package set it should > produce. It's better to let Peter describe it: > https://youtu.be/TDnZsBxqeBM?list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy&t=1850 > > (I think) Rok Garbas, has a good question at the end! > > Anyway, I just wanted to raise this subject / see if this is an issue > people are interested in. > ___ > 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] dosbox
Hi, This has already been fixed in 3db3355c835622123245515cdba65edb274e9e7b. Thanks anyway! On 04/25/2016 10:31 AM, Karn Kallio wrote: > > The attached patch fixes the dosbox build by adding mesa. > > > > ___ > 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
Re: [Nix-dev] phonon adjustment
On Mon, Apr 25, 2016 at 2:30 AM, Karn Kallio wrote: > > The attached patch to phonon adds a fragment of the change from > staging sufficient to fix the kde5 build in current master, without > patching paths in includes. > > This will make kde5 components (eg dolphin, gwenview) build in master > until the staging arrives. > Merged at b6e63fba6deebd3b65b3db0fbcb7f2a18e162f0d. Thanks! -- Thomas Tuegel ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell structure for all of nixpkgs
Hi Tomasz, On Sun, Apr 24, 2016 at 6:12 PM, Tomasz Czyż wrote: > do you have any description of what you are exactly talking about? Adopting this approach brings a huge amount of flexibility, could be that this style of structuring can be rolled out for different languages. Sure there are differences in how languages publish packages, but it could be Peter's solution is a 80% solution applicable to most languages. This approach might mean if nixers want support for a new language they could plug into this this rather advanced packaging structure and hopefully it works out well. Existing supported languages on Nix could start converging onto this style of packaging. The current setup is each language has their own ad hoc solution for getting packages, these packages are tightly bound. So in the current setup, callPackage refers to a specific file, whereas in the haskell setup the callPackage refers to a specific recursive set of expressions that are self contained. The package set is a function which produces a package set. This function takes an argument which produces a package set it should produce. It's better to let Peter describe it: https://youtu.be/TDnZsBxqeBM?list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy&t=1850 (I think) Rok Garbas, has a good question at the end! Anyway, I just wanted to raise this subject / see if this is an issue people are interested in. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pgadmin
It appears this issue was fixed in 9ad2832b1bf6897d already. Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] dosbox
The attached patch fixes the dosbox build by adding mesa.
>From 29934ae6570cf1c6e884d3a9364a9eeaeeaddfdc Mon Sep 17 00:00:00 2001
From: Karn Kallio
Date: Mon, 25 Apr 2016 01:36:38 -0430
Subject: [PATCH] dosbox : add mesa to fix build
---
pkgs/misc/emulators/dosbox/default.nix | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/pkgs/misc/emulators/dosbox/default.nix b/pkgs/misc/emulators/dosbox/default.nix
index 2525caf..15bb562 100644
--- a/pkgs/misc/emulators/dosbox/default.nix
+++ b/pkgs/misc/emulators/dosbox/default.nix
@@ -1,4 +1,4 @@
-{ stdenv, fetchurl, SDL, makeDesktopItem }:
+{ stdenv, fetchurl, SDL, mesa, makeDesktopItem }:
stdenv.mkDerivation rec {
name = "dosbox-0.74";
@@ -17,9 +17,11 @@ stdenv.mkDerivation rec {
];
patchFlags = "-p0";
+
+ #configureFlags = [ "--disable-opengl" ];
- buildInputs = [ SDL ];
-
+ buildInputs = [ mesa SDL ];
+
desktopItem = makeDesktopItem {
name = "dosbox";
exec = "dosbox";
--
2.8.0
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] phonon adjustment
The attached patch to phonon adds a fragment of the change from
staging sufficient to fix the kde5 build in current master, without
patching paths in includes.
This will make kde5 components (eg dolphin, gwenview) build in master
until the staging arrives.
>From 356a3dd9a6aea672adf8a234e60f5fa9a33b75c9 Mon Sep 17 00:00:00 2001
From: Karn Kallio
Date: Mon, 25 Apr 2016 01:00:06 -0430
Subject: [PATCH] phonon : fix configuration paths
---
pkgs/development/libraries/phonon/default.nix | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/pkgs/development/libraries/phonon/default.nix b/pkgs/development/libraries/phonon/default.nix
index 3c731ca..db4c237 100644
--- a/pkgs/development/libraries/phonon/default.nix
+++ b/pkgs/development/libraries/phonon/default.nix
@@ -47,8 +47,8 @@ stdenv.mkDerivation rec {
postPatch = ''
sed -i PhononConfig.cmake.in \
-e "/get_filename_component(rootDir/ s/^.*$//" \
--e "s,\\(set(PHONON_INCLUDE_DIR\\).*$,\\1 \"''${!outputDev}/include\")," \
--e "s,\\(set(PHONON_LIBRARY_DIR\\).*$,\\1 \"''${!outputLib}/lib\")," \
--e "s,\\(set(PHONON_BUILDSYSTEM_DIR\\).*$,\\1 \"''${!outputDev}/share/phonon${if withQt5 then "4qt5" else ""}/buildsystem\"),"
+-e "/^set(PHONON_INCLUDE_DIR/ s,\''${rootDir},''${!outputDev}," \
+-e "/^set(PHONON_LIBRARY_DIR/ s,\''${rootDir}/,," \
+-e "/^set(PHONON_BUILDSYSTEM_DIR/ s,\''${rootDir},''${!outputDev},"
'';
}
--
2.8.0
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
