Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub
This is _exactly_ the reason why I moved all rust machinery into fractalide before I deprecated it completely. The upstream nixpkgs rustRegistry wasn't keeping up with my newly published rustfbp crate. By having the machinery in fractalide I could bump the registry without making week long turn around times to nixpkgs. I asked you to nix-collect-garbage to remove all that crap, the new error indicates the true source of the problem. This error is a combination of the idiocy of semantic versioning, a non-hermetically sealed rust machinery in nixpkgs and cargo's he-man approach to a build system. Please update the rustRegistry and try again. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub
I mean rustRegistry now ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub
Okay, progress. No it's not exactly the same as it's not hermetically sealed. You need to update the rustIndex in nixpkgs. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub
$ nix-garbage-collect then retry ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Rust prebuilt package overlay.
Great stuff Nicolas, much appreciated! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why having releases if you break things in it often
Welcome Stefan, Put all that stuff aside for the moment, just a moment, and work your way through this tutorial https://nixcloud.io/tour/?id=1. If once done, you decide nix isn't for you then drop it. If something switches on in your head keep at it cause you'll now have all the tools needed to unlock nix/os. Any other method other than learning the language is a waste of time IMHO, fortunately nix is a very nice language and will make your fingertip an order of magnitude more powerful. kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] purescript takes 4+ hours to build a hello world app on nixos
On Mon, Jan 30, 2017 at 1:02 AM, Sergei Trofimovich wrote: > On Sun, 29 Jan 2017 18:48:14 +0800 > Your system time > > real22m21.918s > user13m49.982s > sys 23m1.702s > > suggests something is seriously off on your system. > Perhaps machine is swapping heavily. > > If it works that long for you you should be able > to explore the problem as it goes with tools like > 'perf top', 'strace' and others. If I do this: $ mkdir tempdir $ cd tempdir $ npm install bower pulp $ ./node_modules/.bin/pulp init $ time ./node_modules/.bin/pulp build * Building project in /home/stewart/dev/fractalide/capnpc-purescript * Build successful. real0m1.127s user0m1.342s sys 0m0.188s Regarding swap: Also when I checked htop during the `nix-build` in nix-purescript-skeleton repo swap shows no indication of thrashing. Kinda nasty using perf top due to permission issues. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] purescript takes 4+ hours to build a hello world app on nixos
I'm confounded by this issue, I'd like to know if anyone on nixos can reproduce this behaviour. https://github.com/purescript/purescript/issues/2598 There are easy steps to reproduce on the issue description. Note it doesn't seem to exhibit when using nix on ubuntu etc. If you can repoduce the issue on nixos please add to the issue comments, to provide more evidence. I've tried compiling against nixos-unstable and nixpkgs head. kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator
see https://github.com/NixOS/hydra/issues/444 On Thu, Jan 19, 2017 at 1:53 AM, Christian Theune wrote: > Hi, > > On 18 Jan 2017, at 18:33, Jean-Pierre wrote: > > New version of hydra (2016-12-09) override gcc to gcc6 > > https://github.com/NixOS/hydra/blob/aef048b3cb3a7db25b1c48366f266031c5905c0b/release.nix#L127 > > > yeah, that’s what I’m using. I’m currently struggling trying to find a good > base channel for the system (16.09 vs unstable) and a version of hydra, > either by fetching the full module from the repo, … > > The newest version I could manage to get working had problems with the bzip > perl module … > > I’ll give up the yak shaving for today, I guess. I had a working > intermediate setup where the evaluation was still spinning and we’ll likely > debug that tomorrow trying to find the part of the change that triggers > this. > > Cheers, > Christian > > -- > Christian Theune · c...@flyingcircus.io · +49 345 219401 0 > Flying Circus Internet Operations GmbH · http://flyingcircus.io > Forsterstraße 29 · 06112 Halle (Saale) · Deutschland > HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. > Zagrodnick > > > ___ > 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] Hydra: infinite CPU and RAM consumption in evaluator
The next problem you will have is this: https://github.com/NixOS/hydra/issues/445 remove those changes and you will be able to add jobsets. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Call For Maintainers - Fractalide BETA release
Reusable Functions - They're great, they're just great, you'll love them. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Call For Maintainers - Fractalide BETA release
On Thu, Jan 12, 2017 at 8:46 PM, Herwig Hochleitner wrote: > ... Nix's very existence revolves around solving an insanely hard problem, that of reproducibility, it's the only project that actually gets it right. Reproducible monolith apps have _everything_ to do with Nix/NixOS Reproducible libraries have _everything_ to do with Nix/NixOS Reproducible functions adds a new vertical design space to Nix/NixOS, it's pretty huge in my books, given that monolith apps can be combined in only a certain amount of ways. Next came the reproducible libraries, which can be combined into even more ways. Now this new feature introduces a whole new level of mix-and-matchability. As for stealing from the community, this is not a zero sum game. I'd suggest otherwise, it promotes adoption of Nix/NixOS. There are sane development processes and software architecture principles there. Should a company choose to adopt developing their servers in this style it increases the Nix/NixOS community by one more company, it also saves them boat loads of firefighting, bugs, bad architecture, bloat and all sorts of nastiness down the line. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Call For Maintainers - Fractalide BETA release
So let me understand this clearly. Reusable and reproducible functions have nothing to do with Nix/NixOS? What about reproducible libraries? What about reproducible monolith apps? This is a _new_ concept to the Nix/NixOS ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Call For Maintainers - Fractalide BETA release
On Thu, Jan 12, 2017 at 7:03 PM, Profpatsch wrote: > Not sure what this has to do with nix-dev? tough crowd, tough crowd. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Call For Maintainers - Fractalide BETA release
Greetings all, So after some 946 commits a number of rewrites starting in 2014 when Fractalide was implemented in a neat programming language called Mozart Oz, we've gone BETA. At that stage Fractalide was the subject of a Master thesis for Denis Michiels under Professor Peter Van Roy of UCL Belgium (Peter is a co-author of the book Concepts Techniques and Models of Computer Programming). Both Peter and Denis are fantastic fellows. Since then Fractalide has moved out of academia and into industry reincarnated as Rust and Nix. I had the good fortune of meeting Denis face to face in Belgium last year when we had our first "fraconf" of only two participants! Hopefully this conference can grow in numbers :-) It would seem that Fractalide does in fact occupy a very important part of the industry. Dataflow languages in the form of Ab Initio [0] serve enterprises and charge a very heavy price tag. A couple of years ago Google implemented this dataflow programming language called TensorFlow, it's aimed at Machine Learning but it has other uses. The NSA also open sourced their dataflow programming language called Niagrafiles, now renamed to Apache-NiFi. As each node in Fractalide is essentially a reusable function stuck in a nix derivation one might say that Fractalide adds "Nixfuncs" to "Nixpkgs", where nixpkgs are monolith applications that don't (rarely?) compose and "nixfuncs" are reusable functions that can compose. It makes sense this general purpose dataflow language needs to specialize in creating reusable, reproducible services, the power of nix makes this quite possible to achieve. It's also a very trendy area, which can lead into an even trendier area that of the Internet of S... Things! There has been a few guiding principles along the path. 1) ensure we have a language that cooperates with a congruent configuration system. 2) safety both within and outside the application boundary. 3) primitives that make executing in a distributed environment easier to reason about. 4) fast, fast as greased lightning. Going BETA means it's a signal to the public that underlying nodes are headed for stable and their public APIs won't change with a high probability. After stabilization they won't ever be deleted or changed. In other words Fractalide is going to be a rock solid platform to build things on, for decades to come. We're not yet ready to go STABLE because there are a few things in Nix that need to happen such as the landing of this [1], which has this: [2] and nixcrates needs a final round of work elbow work. We're adopting the Pieter Hintjens style of community, whereby, should jobs come in they get farmed out to trusted contributing members of the community. This approach is more like forming an IETF group who ralley around problems and solve them quickly, efficiently then share the spoils, going back to their daily lives. These brilliant types of people rarely tolerate enterprise environments and prefer working independently or in small groups. Basically our company Noware Ltd. is giving the Fractalide codebase away to the community, copyright is spread far and wide to prevent corporate takeover and lockins, so as a whole the community grows it into highly evolved software. As Fractalide is so heavily dependent on Nix, it's fair to hand over a percentage of the earnings to the Nix Foundation to help keep the lights on. On that note, if you're in business and you have expensive problems you want to solve that fit Fractalide's domain please lets get in touch. I'd like to start repaying favours the nix community has offered me. Onto some code. So this is a contrived example of an NAND `agent`, (it's not a real world node): #[macro_use] extern crate rustfbp; extern crate capnp; agent! { input(a: prim_bool, b: prim_bool), output(output: prim_bool), fn run(&mut self) -> Result { let a = { let mut msg_a = try!(self.input.a.recv()); let boolean: prim_bool::Reader = msg_a.read_schema()?; boolean.get_bool() }; let b = { let mut msg_b = try!(self.input.b.recv()); let boolean: prim_bool::Reader = msg_b.read_schema()?; boolean.get_bool() }; let mut out_msg = Msg::new(); { let mut boolean = out_msg.build_schema::(); boolean.set_bool(if a == true && b == true {false} else {true}); } try!(self.output.output.send(out_msg)); Ok(End) } } Here is the associated nix code that sets up the dependencies needed to build the above NAND `agent` { agent, edges, crates, pkgs }: agent { src = ./.; edges = with edges; [ prim_bool ]; crates = with crates; [ rustfbp capnp ]; osdeps = with pkgs; []; } This code can be executed by running: $ git clone https://github.com/fractalide/fractalide.git $ cd fractalide $ nix-build --argstr node test_nand $ ./result boolean : false The arguments `--argstr node test_nand` build a file that looks like this: $ cat /nix/store/kzw9p6a1snkhswwlnzb0i2a5rzg9vymd-test_nand /ni
Re: [Nix-dev] permission problems
Oh great, look forward to that landing. On Wed, Jan 11, 2017 at 7:00 PM, Domen Kožar wrote: > https://github.com/NixOS/nixpkgs/issues/20156 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] permission problems
Peter, Bas, Thank you so much for this information. :-) Is anybody working on bringing in the new systemd? Can I get started on it? kr/sjm On Wed, Jan 11, 2017 at 6:26 PM, Peter Hoeg wrote: > Hi Stewart, > >> I don't suppose there is some sort of convention, i.e. for lightweight >> throw away services? See I'm creating a programming language aimed at >> making tiny services, kinda like trensorflow, not applied to machine >> learning but applied to this new fangled concept called microservices >> - complete hype atm but it's fun. I'm kinda hoping these tiny services >> are created and shared with the community, but they'd need not >> conflict with each other. >> >> In other words I think I'm going to need some kind of id namespace >> allocation or something to that effect. > > > When systemd 232 hits nixpkgs, you get it for free: > > https://github.com/systemd/systemd/blob/master/NEWS#L53 > > -- > Regards, > Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] permission problems
On Wed, Jan 11, 2017 at 4:11 PM, Bas van Dijk wrote: > Hi Stewart, > > config.ids.uids.workbench doesn't seem to exist in: > > https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix > > Why do you assume it's there? Which revision of nixpkgs are you using? Good question, I suppose, I don't know why I assumed it, I thought it would be generated or something. I don't recall seeing this: .../nixos/modules/misc/ids.nix anywhere in the docs. Anyway the only service I've contributed is zerotierone so experience is limited there. Though this does explain why I get my error, and will hopefull solve my permission problem! I don't suppose there is some sort of convention, i.e. for lightweight throw away services? See I'm creating a programming language aimed at making tiny services, kinda like trensorflow, not applied to machine learning but applied to this new fangled concept called microservices - complete hype atm but it's fun. I'm kinda hoping these tiny services are created and shared with the community, but they'd need not conflict with each other. In other words I think I'm going to need some kind of id namespace allocation or something to that effect. How to proceed forward? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] permission problems
greetings, If I enable this: https://github.com/fractalide/fractal_workbench/blob/master/service.nix#L72 I get $ sudo nixos-rebuild test -I fractalide=/home/stewart/dev/fractalide/fractalide [sudo] password for stewart: building Nix... building the system configuration... error: attribute ‘workbench’ missing, at /home/stewart/dev/fractalide/fractals/fractal_workbench/service.nix:72:13 (use ‘--show-trace’ to show detailed location information) why can't I add` uid = config.ids.uids.workbench;`? --- I'm trying to debug a permission problem in that the application doesn't have permission to access the database. kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Remapping Console Key Bindings
services.xserver.xkbOptions = "grp:alt_space_toggle, ctrl:swapcaps"; ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Introducing Nixpkgs Overlays
Hello Nicolas, I support this work. It would make layering of fractalide on nixpkgs easier, also the layering of a developer's set of agents on top of fractalide would be easier and cleaner. I really hope this lands. kudos kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Rebuild a derivation
Change a single character, rebuild, satisfy ocd, restore src back to original state, rebuild. I'd also like an answer to this question, but I've found it's not really needed. Nix is very clear about changing deps. ___ 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
For me the crux is the nix expression language, everything revolves around this, this is where real tangible value (read as eye opening, toe curling power) is obtained. It might be a good idea creating a nixmake.com or xmake.com site which has a page for most popular languages detailing documentation on the subject. The name nixmake is close to make, cmake and every other make system. It's not alien and that name is humble enough to be installed on a programmer's system. Promote nixmake as a viable language level build system, every language needs such a system. Now here's the key point. It's a helluva lot easier getting into nixos, nixpkgs, hydra, nixops once you learn the nix expression language, make the nixmake concept the gateway drug, as you're proposing a nice solution to a problem close to many programmer's daily work, shortly they end up seeing the whole picture. Now when I say make nix as a language package manager, I mean do things like this: https://github.com/fractalide/nixcrates (I contracted the awesome https://nixcloud.io team to make nixcrates for Fractalide, btw they also made https://nixcloud.io/tour/?id=1 so this tour of nix should have a prominent place on this hypothetical nixmake.com). Hence programmers would write default.nix files instead of CMakeLists Makefile Cargo.toml etc files. Get nix to schew language level build systems and construct arguments for the different compilers directly. my 2c worth kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Reproducibility testing in Hydra
Massive achievement! Congrats to all involved! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hotswappable self managing services in nix
zimbatm, i appreciate you sharing your insight and experience, my main exposure to this is the Erlang Way tm. Many good lessons can be drawn from this level of engineering. I'm not too fussed about the network level (inter machine) at this moment. Inter-service we're using a component that wraps nanomsg. After a bit of thought, we're redesigning the rustfbp scheduler/vm to be more like the way nix operates. i.e. as declarative as possible, we cannot have silly imperative state fiddling at all, i.e. you cannot log into a fractalide node and start connecting / disconnecting components, this would be like making the /nix/store/ writable and messing with that. The new design is this: you load a nix compiled hierarchy of components into the fractalide virtual machine (fvm) then if you want to make a mistake, and want to change it you'll issue a $ fvm reload ${new_subnet_hierarchy} and fvm will then kill/start/hotswap all rust components that aren't/are in your new description of the graph. Just as nixos-rebuild makes your system reflect your Configuration.nix file, so fvm will reconfigure the component graph in the process to reflect what nix compiled. Once we get this layer, then we can "surf" with nix and just let nix/nixops manage the rest. We can implement blue/green styles of deployment in nixops *.nix files. That's another layer of problems still to come. Phew... On Mon, Nov 28, 2016 at 5:33 PM, zimbatm wrote: > Hi Stewart, > > In a HA setup availability is generally achieved on a network level instead > of system level. Typically you would have two hotswappable load-balancers > that distribute the traffic to multiple instances of your service boxes. In > that context is doesn't matter how processes are being restarted because the > load-balancer will automatically detect unresponsive machines and route the > traffic accordingly. It's also handy because it allows to restart the > machines in the event where the kernel needs an upgrade. In that setup I > suppose you can think of each machine as being one Erlang OTP "process" and > the network the "message-passing". > > One responsibility of the service in that setup is to shutdown properly to > avoid unnecessary disruption of service. Mainly when the process gets the > SIGTERM signal it should close the listening socket (so the load-balancer > can route new incoming connections to a different machine) and then drain > the existing client connection gracefully. It shouldn't stop all at once but > let the clients disconnect when they are done with their sessions (and > optionally signal them to go away if the protocol supports it). > > A last thing regarding this approach: generally you need a way to control > the deploys; if all the service boxes are being upgraded at the same time > then the load-balancer doesn't have anywhere to route the traffic to. It's > also something desirable to have to do blue/green deployments. > > I need to stop there for now but I also have a similar design answer on the > system level where processes get replaced gracefully. > > Cheers, > z > > On Sun, 27 Nov 2016 at 04:33 stewart mackenzie wrote: >> >> 9 9s not unheard of in these circles, Google uptimes are a joke not worthy >> of mention. >> >> There are systems that have been running for some 40 odd years in >> production that factor in changes to legal banking regulations, hardware, >> business logic etc. Erlang has a system called the Ericsson AXD301 which has >> achieved this time frame. >> >> Just because Nixos hasn't been around that long doesn't mean it can't have >> the primitives to allow for such feats. Its these primitives I'm enquiring >> about. >> >> So let's use a new, less controversial figure of 5 9s and keep on topic. >> >> The thing is, we're designing this system so that its governed by nix >> don't necessarily have to depend heavily on the runtime - I really don't >> want to go down the imperative route, by introducing imperative language >> concepts into our declarative language which is managed by another >> declarative language (nix). Besides just bringing in a single component with >> an OS Dependency demands we manage this change from nix level. >> >> We currently have a hack in place, that will resolve dependencies and give >> us a path to load a correctly compiled shared object into memory: >> https://github.com/fractalide/fractalide/blob/master/components/nucleus/find/component/src/lib.rs#L43 >> nasty and cringe worthy I know. >> >> Thanks for your pointer, I'll take a look at these activation scripts. >> >> Maybe this hack is the answer, and confine the dynamism to an ssh login al >> a Erlang style... >> >> ___ >> 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] hotswappable self managing services in nix
9 9s not unheard of in these circles, Google uptimes are a joke not worthy of mention. There are systems that have been running for some 40 odd years in production that factor in changes to legal banking regulations, hardware, business logic etc. Erlang has a system called the Ericsson AXD301 which has achieved this time frame. Just because Nixos hasn't been around that long doesn't mean it can't have the primitives to allow for such feats. Its these primitives I'm enquiring about. So let's use a new, less controversial figure of 5 9s and keep on topic. The thing is, we're designing this system so that its governed by nix don't necessarily have to depend heavily on the runtime - I really don't want to go down the imperative route, by introducing imperative language concepts into our declarative language which is managed by another declarative language (nix). Besides just bringing in a single component with an OS Dependency demands we manage this change from nix level. We currently have a hack in place, that will resolve dependencies and give us a path to load a correctly compiled shared object into memory: https://github.com/fractalide/fractalide/blob/master/components/nucleus/find/component/src/lib.rs#L43 nasty and cringe worthy I know. Thanks for your pointer, I'll take a look at these activation scripts. Maybe this hack is the answer, and confine the dynamism to an ssh login al a Erlang style... ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hotswappable self managing services in nix
Let me rephrase the question. Is it possible to build a highly available system on nix such that SLA uptimes of 9 9s. (99.999 % uptime) are achievable? If so what primitives does nix offer to allow this to happen? Such primitives should be: the ability for nix to invoke the hotswapping capabilities of a live running system. Now just connecting to Erlang and making changes isn't good enough. Why? - nix cannot see those "imperative" changes. Git vs svn, git takes the global view and svn the file view. Git got it right, you need to factor in the entire repo's changes. Nix gets it right too by looking at this from an entire system perspective, so I'm seeking a way to introduce change to a live fractalide system from a nix level, though it mustn't be a "connect to fractalide via ssh and change it there" approach. Making changes to Erlang via ssh under Nix management is like having a declarative system then introducing imperative mechanisms. I need a formalized method to ensure global determinism yet be able to make changes to a live running system from nix. Are there any Erlangers here who achieve huge uptimes on nix? If so how do you do it? How do you make use of Erlang's hotswapping mechanisms yet retain the lovely system wide determinism nix offers. kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] hotswappable self managing services in nix
Hi Nixers, Say you have a service and you make a change to the service code. Nix will restart the service. Now say my service code is smart enough to do hot swapping of components al a Erlang style. Is it possible to tell nix not to restart the service but instead give the running executable a long string and let the executable be responsible for making changes to it's environment in a declarative manner? kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] getting dependencies
okay this bit of code did it: ... propagatedBuildInputs = importedContracts; installPhase = '' runHook preInstall mkdir -p $out/src mkdir -p $out/nix-support for i in $importedContracts; do echo $i >> $out/nix-support/propagated-build-inputs done propagated="" for i in $importedContracts; do findInputs $i propagated propagated-build-inputs done echo $propagated cp ${contractText} $out/src/contract.capnp ${capnproto}/bin/capnp compile -o${capnpc-rust}/bin/capnpc-rust:$out/src/ $out/src/contract.capnp --src-prefix $out/src/ -I "/" ''; ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] getting dependencies
Greetings, The actual code in question is here: https://github.com/fractalide/fractalide/blob/master/contracts/list/command/default.nix Notice all the duplication! My problem: Achieve Contract Composition! This is where Command should be - without the Tuple duplication!: https://github.com/fractalide/fractalide/blob/master/contracts/command/default.nix This is where Tuple should be: https://github.com/fractalide/fractalide/blob/master/contracts/tuple/default.nix Each derivation will generate a *.rs file from a *.capnp file. This is the technique capnproto uses to import another capnproto file: ``` # /nix/store/...-bar/src/contract.capnp @0x8744595ef8d1c0ed; struct Bar { a @0 :Text; } ``` and in a separate derivation ``` # /nix/store/...-qux/src/contract.capnp @0x99055c3145684b93; using Bar = import "${bar}/src/contract.capnp"; struct Qux { a @0 :List(Bar.Bar); } ``` (that ${bar} is nix code! I'm omitting the { bar }: at the top of the file) The compilation of Qux works but when a component imports the generated Qux.rs code and compiles Qux it will fail because there is no generated Bar.rs code present, and therefore there are unresolved dependencies on Bar. A possible way to work around this is: What I need to do is have a list of all the dependencies of Qux and then concatenate the results of all the dependency derivation's *.rs together into one final Qux.rs file. This would then satisfy any component that uses Qux.rs My question: how do I get a *unique* list of all the dependencies of Qux? If it's not unique I could run into name collisions when compiling the concatenated list. This has to be a common issue and there must be a simple solution in nix. Now I need help with my incompetence please. I looked at propagatedBuildInputs, but it doesn't seem to work. Why? Z depends on Y Y depends on X When I compile Z, X does not appear in any of the env-vars fields! Only Y appears in an environment variable called propagatedNativeBuildInputs (whatever that is, there doesn't seem to be any documentation on propagatedNativeBuildInputs) Despite the documentation saying otherwise. Secondly I cannot find a nix-support/propagated-build-inputs file anywhere. here is the documentation: "propagatedBuildInputs Like buildInputs, but these dependencies are propagated: that is, the dependencies listed here are added to the buildInputs of any package that uses this package as a dependency. So if package Y has propagatedBuildInputs = [X], and package Z has buildInputs = [Y], then package X will appear in Z’s build environment automatically." Using this logic, I would need to include any dependent contract in both the buildInputs and propagatedBuildInputs, so that contracts would propagate "upstream". This also doesn't seem to work. What am I missing? kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] svanderburg/disnix migrate to nixos/disnix
I'm exploring this software now and it excites me, I'm currently trying to get dysnomia installed, would be perfect if there was a disnix/default.nix that'll just automate all that away (for those nixos users). I keep shying away from building subnets that are services in github.com/fractalide/fractalide because services need the nixos layer to automate everything. It would seem that by using disnix I'll be able to deploy fractalide services in a destributed environment. Is this accurate? kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] svanderburg/disnix migrate to nixos/disnix
Hi Sander + all, Disnix looks like a very interesting piece of software, would it be a good idea to move disnix to the main nixos/ organization? kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] obtaining the drv from an imported object
ah yes, this is my solution: https://github.com/fractalide/frac_example_wrangle { fractalide ? import {} , pkgs ? fractalide.pkgs , support ? fractalide.support , contracts ? fractalide.contracts , components ? fractalide.components}: let publicComponentOrSubnet = allComponents.example_wrangle; # expose your public reusable subnet exeSubnet = allComponents.example_wrangle; # a subnet containing non-generic IIPs you don't want to expose to the community allContracts = contracts // import ./contracts {inherit pkgs support allContracts;}; allComponents = components // import ./components {inherit pkgs support allContracts allComponents;}; in if fractalide == null then publicComponentOrSubnet else import ( + "/support/vm/") {inherit pkgs support; contracts = allContracts; components = allComponents; exeSubnet = exeSubnet;} it was late, cause my brain wasn't working properly. Thanks mate kr/sjm On Mon, Oct 24, 2016 at 3:38 PM, zimbatm wrote: > I think what you want is something in this effect: > > let src = fetchTarball ...; fractalide = import src {}; > ... > else import "${src}/support/vm" {}; ... > > Alternatively you could require the user to set the fractalide source into > the NIX_PATH which gives her the choice of using a remote or local checkout. > NIX_PATH="$NIX_PATH fractalide=https://..."; > In the code you can then access that using the notation. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] obtaining the drv from an imported object
Greetings, I have a specialization repo for fractalide i.e. the repos may import each others components and contracts. They are just specializations / experimental places (https://github.com/fractalide/fractalide_external_opensource_example) I want the specialization repo to be importable by canonical i.e: https://github.com/fractalide/fractalide/blob/master/components/vendor/external/opensource/example/default.nix#L11 and I also want the programmer to be able to `cd specialization/` and then build a vm right there instead of having to go into the fractalide repo to build the vm. This is the code I have so far for this repo https://github.com/fractalide/fractalide_external_opensource_example/default.nix { fractalide ? import (fetchTarball https://github.com/fractalide/fractalide/archive/master.tar.gz) {} , pkgs ? fractalide.pkgs , support ? fractalide.support , contracts ? fractalide.contracts , components ? fractalide.components}: let publicComponentOrSubnet = allComponents.vendor_test_nand; allContracts = contracts // import ./contracts {inherit pkgs support allContracts;}; allComponents = components // import ./components {inherit pkgs support allContracts allComponents;}; componentOrSubnetOrVm = if fractalide == null then publicComponentOrSubnet else import fractalide { inherit pkgs support allContracts allComponents; exeSubnet = publicComponentOrSubnet;}; in componentOrSubnetOrVm The line in question is this one: else import fractalide { inherit pkgs support allContracts allComponents; exeSubnet = publicComponentOrSubnet;}; I want to find the drv of fractalide so I can `else import fractalide.drv/support/vm { ...} (to that effect) where the path points to this file: https://github.com/fractalide/fractalide/blob/master/support/vm/default.nix How do I obtain the drv? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] error: stack overflow (possible infinite recursion) && builtins.match isn't documented
Hello, I've just stumbled on a treasure: https://github.com/NixOS/nix/blob/master/src/libexpr/primops.cc#L1937 I'm curious to know why such an important builtin isn't documented here: http://nixos.org/nix/manual/ I'm unusually excited about find, as demonstrated by opening the email with this topic lest I forget my original problem is: I'm getting an error: hydra-eval-jobs returned exit code 1: error: stack overflow (possible infinite recursion) when using hydra to build fractalide, the only mention of the above error is here: https://github.com/NixOS/nixpkgs/issues/16570 Now I doubt the overflow is due to my splitString usage here: https://github.com/fractalide/fractalide/blob/master/support/genName.nix#L8 , as the paths are quite small. Where typically does one come across hydra stack overflows? I'm using hydra master head. These are my nixops parameters: deployment.targetEnv = "virtualbox"; deployment.virtualbox.memorySize = 4096; # Mbytes deployment.virtualbox.headless = true; I really just want to ping the community before I start digging down a lot of rat holes. kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pass a text file on the internet through <>
Yes you're right a separate arg should be used. Still the <> seems like a wonderful tool and limiting it just to tarballs seems a bit of a waste. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] pass a text file on the internet through <>
Greetings, In my nix code I make use of a <>, when executing the nix-build command I use `-I fractalide_user=https://keybase.io/iElectric/key.asc` (I chose iElectric cause it was convenient) [stewart@rivergod:~/dev/fractalide/fractalide]$ nix-build --argstr debug true --argstr cache $(./support/buildCache.sh) --argstr subnet shells_lain_commands -I fractalide_user=https://keybase.io/iElectric/key.asc downloading ‘https://keybase.io/iElectric/key.asc’... [2/2 KiB, 1.5 KiB/s] unpacking ‘https://keybase.io/iElectric/key.asc’... tar: This does not look like a tar archive tar: Skipping to next header tar: Exiting with failure status due to previous errors error: program ‘tar’ failed with exit code 2 (use ‘--show-trace’ to show detailed location information) Surely one should be able to pass text files over this medium? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Rust: "error: failed to load source for a dependency on ..."
Hi, I've `sudo nixos-rebuild --upgrade switch` 'ed and things stopped working. steps to reproduce: $ nix-build --argstr debug true --argstr cache $(./support/buildCache.sh) -A components.nucleus_find_contract (this command currently won't work on HEAD as Please note there is no mention git repositories in the Cargo.toml file, which seems to be the common source of this error on nix. Does someone know what's going on with this error? CARGO.TOML [package] name = "component" version = "0.1.0" authors = ["test "] [lib] name = "component" crate-type = ["dylib"] [dependencies] capnp = "*" rustfbp = "*" CARGO.LOCK [root] name = "nucleus_find_contract" version = "0.1.0" dependencies = [ "capnp 0.7.4 (registry+file:///dev/null)", "rustfbp 0.3.18 (registry+file:///dev/null)", ] [[package]] name = "byteorder" version = "0.4.2" source = "registry+file:///dev/null" [[package]] name = "capnp" version = "0.7.4" source = "registry+file:///dev/null" dependencies = [ "byteorder 0.4.2 (registry+file:///dev/null)", ] [[package]] name = "dtoa" version = "0.2.2" source = "registry+file:///dev/null" [[package]] name = "itoa" version = "0.1.1" source = "registry+file:///dev/null" [[package]] name = "kernel32-sys" version = "0.2.2" source = "registry+file:///dev/null" dependencies = [ "winapi 0.2.8 (registry+file:///dev/null)", "winapi-build 0.1.1 (registry+file:///dev/null)", ] [[package]] name = "lazy_static" version = "0.2.1" source = "registry+file:///dev/null" [[package]] name = "libloading" version = "0.2.4" source = "registry+file:///dev/null" dependencies = [ "kernel32-sys 0.2.2 (registry+file:///dev/null)", "lazy_static 0.2.1 (registry+file:///dev/null)", "target_build_utils 0.1.1 (registry+file:///dev/null)", "winapi 0.2.8 (registry+file:///dev/null)", ] [[package]] name = "num-traits" version = "0.1.36" source = "registry+file:///dev/null" [[package]] name = "rustfbp" version = "0.3.18" source = "registry+file:///dev/null" dependencies = [ "capnp 0.7.4 (registry+file:///dev/null)", "libloading 0.2.4 (registry+file:///dev/null)", "threadpool 1.3.2 (registry+file:///dev/null)", ] [[package]] name = "serde" version = "0.8.11" source = "registry+file:///dev/null" [[package]] name = "serde_json" version = "0.8.2" source = "registry+file:///dev/null" dependencies = [ "dtoa 0.2.2 (registry+file:///dev/null)", "itoa 0.1.1 (registry+file:///dev/null)", "num-traits 0.1.36 (registry+file:///dev/null)", "serde 0.8.11 (registry+file:///dev/null)", ] [[package]] name = "target_build_utils" version = "0.1.1" source = "registry+file:///dev/null" dependencies = [ "serde_json 0.8.2 (registry+file:///dev/null)", ] [[package]] name = "threadpool" version = "1.3.2" source = "registry+file:///dev/null" [[package]] name = "winapi" version = "0.2.8" source = "registry+file:///dev/null" [[package]] name = "winapi-build" version = "0.1.1" source = "registry+file:///dev/null" [metadata] "checksum byteorder 0.4.2 (registry+file:///dev/null)" = "96c8b41881888cc08af32d47ac4edd52bc7fa27fef774be47a92443756451304" "checksum capnp 0.7.4 (registry+file:///dev/null)" = "476c6a1bba39763a198092e54dec50113c48478dbe031385acfecbae70bac1bd" "checksum dtoa 0.2.2 (registry+file:///dev/null)" = "0dd841b58510c9618291ffa448da2e4e0f699d984d436122372f446dae62263d" "checksum itoa 0.1.1 (registry+file:///dev/null)" = "ae3088ea4baeceb0284ee9eea42f591226e6beaecf65373e41b38d95a1b8e7a1" "checksum kernel32-sys 0.2.2 (registry+file:///dev/null)" = "7507624b29483431c0ba2d82aece8ca6cdba9382bff4ddd0f7490560c056098d" "checksum lazy_static 0.2.1 (registry+file:///dev/null)" = "49247ec2a285bb3dcb23cbd9c35193c025e7251bfce77c1d5da97e6362dffe7f" "checksum libloading 0.2.4 (registry+file:///dev/null)" = "eceb2637ee9a27c7f19764048a9f377e40e3a70a322722f348e6bc7704d565f2" "checksum num-traits 0.1.36 (registry+file:///dev/null)" = "a16a42856a256b39c6d3484f097f6713e14feacd9bfb02290917904fae46c81c" "checksum rustfbp 0.3.18 (registry+file:///dev/null)" = "fbb4e3c922b153ace2c8094b9fb0d03cbbd9f751886e3669fb0e46350bac0c84" "checksum serde 0.8.11 (registry+file:///dev/null)" = "15db662ce4b837aac5731c52fe732d84a00f909763236289587cb7ca6985f6d8" "checksum serde_json 0.8.2 (registry+file:///dev/null)" = "e5b3bb42fa42265df8a1822b3db2090bc8f9e17e8142599c76a5b854bc4e7b5b" "checksum target_build_utils 0.1.1 (registry+file:///dev/null)" = "7a1be18d4d908e4e5697908de04fdd5099505463fc8eaf1ceb8133ae486936aa" "checksum threadpool 1.3.2 (registry+file:///dev/null)" = "59f6d3eff89920113dac9db44dde461d71d01e88a5b57b258a0466c32b5d7fe1" "checksum winapi 0.2.8 (registry+file:///dev/null)" = "167dc9d6949a9b857f3451275e911c3f44255842c1f7a76f33c55103a909087a" "checksum winapi-build 0.1.1 (registry+file:///dev/null)" = "2d315eee3b34aca4797b2da6b13ed88266e6d612562a0c46390af8299fc699bc" --- ERROR MESSAGE: --- warning: custom registry support via
Re: [Nix-dev] 6 month C4 adoption period
Aye, generally one hopes he rests in peace, but if the cryonics option was chosen then resting in piece is preferable. (I've interacted with him enough to know that he'd laugh like a drain at that and he really wouldn't want us getting all soppy on him.) Domen, just studying the C4 might be insufficient, please can you read the Psychopath Code, Social Architecture, and the Zeromq Manual. For a more general understanding read Culture and Empire. All his material is freely available online, but it might be a good gesture for people who are seriously considering shifting Nixpkgs to C4 to buy his books. The website will probably go down in a couple of years and having hard copies of his thought patterns is good, plus it helps his children to purchase the books. Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS 16.09 released
Congratulations! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hydra.cryp.to will go offline by the end of this year
Never used it, but it very much inspired me! Well done on this work! /sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps usage survey.
Yes, you're deliberately breaking purity, but if you're going to be using it as part of the development infrastruction (he could mean many things, does he mean *code deployment infrastructure* or implicitly implying CDI and explicitly mentioning part of the development infrastructure.) If he means he wishes to use nix as the main way to build the project, (I.e. make replacement, so to say) then he'll very very quickly hit a wall in that he'll be waiting long periods for the project to compile from scratch each time. This is infuriating and incremenal compilation can have a significant positive impact on your development flow. So yes, I will recommend him to break purity in this case, I should have mentioned, when you actually deploy, make sure you haven't enabled this incremenal compilation feature. Keep it pure, but I was going to mention that to him if/when he gets to that bridge so that he doesn't get information overload now. On 6 Sep 2016 06:31, "Shea Levy" wrote: > Please don't recommend turning off > the sandbox unless you are very sure you know what you're doing and that > the person you're recommending it to understands the relevant issues. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps usage survey.
On 6 Sep 2016 00:01, "Aloïs Cochard" wrote: > We do plan to use it for our development infrastructure You'll need to implement incremental recompilation (IR) to reduce compilation times. It's not too difficult to implement if you know _not_ to set nix.useSandbox = true; . Ping me when/if you get to that bridge and I'll assist. Kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained
I would feel very happy with this solution iff meta.maintainers had commit access. Many meta.maintainers do not have commit access, that's the main bottleneck that causes hours/days/weeks/months delay. On 3 Sep 2016 19:25, "Shea Levy" wrote: > 3. We can encourage users to first try to get the attention of the >maintainers of the relevant packages and then escalate to a list of >maintainer maintainers if no response is forthcoming. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Was that offensive? Sorry I thought it was funny. Forgive me I shan't mention nipples again. On 1 Sep 2016 03:51, "Jookia" <166...@gmail.com> wrote: > On Thu, Sep 01, 2016 at 01:17:02AM +0800, stewart mackenzie wrote: > > Throw beers at Garbas! Shower him in the best beer possible! > > > > *Garbas rubs his nipples* > > 2.7.5: > > Administrators SHOULD block or ban "bad actors" who cause stress and pain > to > others in the project. This should be done after public discussion, with a > chance for all parties to speak. A bad actor is someone who repeatedly > ignores > the rules and culture of the project, who is needlessly argumentative or > hostile, or who is offensive, and who is unable to self-correct their > behavior > when asked to do so by others. > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] typed nix
P "Nix won't be complete until it has static typing." Nice. > highly nontrivial... No doubt, but having that speed up would be quite nice. Especially when using nix as a 'replacement' for make. It's the future! What would the language even look like? On 1 Sep 2016 03:29, "Vladimír Čunát" wrote: > There's a ticket open: > https://github.com/NixOS/nix/issues/14 > but IMO someone should first think through the implications, > as I suspect they'll be highly nontrivial... ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Just one? A lunatic, now two? A crowd? Three? A rebellion!? Resist your hatred for SJWs and wear the teeshirt for an email in support please. On 1 Sep 2016 01:48, "obadz" wrote: > On Wed, Aug 31, 2016 at 6:13 PM, stewart mackenzie > wrote: > >> this isn't a technical problem it's a people problem > > > I think there are more people who agree with you on this than you think :-) > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Throw beers at Garbas! Shower him in the best beer possible! *Garbas rubs his nipples* On 1 Sep 2016 01:06, "zimbatm" wrote: > > Related to the original rust frustration, Garbas has started the https://github.com/garbas/nixpkgs-mozilla repo where Mozilla stuff is being compiled. There is no hydra building this yet but that could be a nice place to keep rust nightlies. > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
I'm the canary in this goldmine, and this canary is dead. What I'm about to describe is Amdahl's law biting the ass harder of maintainers as nixpkgs grows in size. It's the reason why maintainers are rudely closing PRs, it's the reason why maintainers are cutting corners themselves yet expect super high standards from contributors. Yes it's bloody annoying having someone who didn't even understand the PR close it. Having @globin close the PR without a complete understanding and he voted against C4 in [2], irritated me. Moritz I beg you to answer this with blood streaming from my eyes, do you think @globin has any incentive to solve my problem? Instead I get comments like "If you calm down I might be interested in putting my time into trying to understand why this isn't affected but I'm quite sure you misinterpret the meaning of lowprio". That's after me waiting hours of compile time, no sleep for a long time. Besides, I could have just created another PR to add lowprio back! Notice eelco saying lowprio is needed yet [1] has landed in mainline. Yes I would need to see if it actually worked on hydra, but I'm the one waiting and learning! If you guys are not prepared to break apart this forming 'in crowd' with the C4, then what are your procedures on removing cultivated bad maintainers, or will you just let this become a systemic problem? I am NOT implying @globin is a bad actor! This current stressful system will turn good actors into bad actors. I now don't care how under pressure you maintainers are... your power structure dictates it, the very power structure you guys uphold and resist my attempts at breaking. You could totally alleviate your self chosen stress by adopting the C4. Maintainers are becoming grumpy, the workload is higher, I had sympathy now I do not. Shall I reciprocate with the same level of rudeness I receive when submitting a patch? I'm getting frustrated not at any individual, you're all, I'm sure, great people I can have a good amount of beer with. It's your power structure I'm rebelling against. It needs to change. Then to have another PR created [1] by the person who didn't take the time or energy to even read or understand the C4. Yes I have no patience for people who do not read or understand something, especially when I've spoken on the topic multiple times, endeavouring to answer questions politely and nicely [2], and then to have a habitual response with the "I'm a stressed maintainer don't bother me" learned attitude. I will no longer write volumes (doing it again ... damn) arguing with maintainers who don't want to read, hence the 1+1=2 response. This Moritz is the straw breaking the camel's back, a long while ago I noticed this rude behaviour of maintainers, which is a direct result of the power structure and decided not to commit or maintain packages on nixpkgs or even "aspire" to become a nix maintainer. Having people go around running algos on your level of commitment is such utter and total bullshit. I get people approaching me out of band suggesting technical solutions to this problem (regarding nixpkgs maintainers), this isn't a technical problem it's a people problem. It's becoming a fiefdom, the in crowd, forgive me, but that annoys me. Maybe I should just stop interacting with the nix crowd? Would you prefer that? If you'll let me maintain 1, only 1 package on nixpkgs - a nix shell I'm developing. That's it I promise. I won't touch any other code. (See how mental that is?) [1] https://github.com/NixOS/nixpkgs/pull/18101/files https://github.com/NixOS/nixpkgs/commit/d4e012780f7eee93f7600d5273edde7470f20c87 [2] https://github.com/NixOS/nixpkgs/issues/17407 [3] https://github.com/NixOS/nixpkgs/pull/18102 Think about it for a second, when has the legal system ever passed laws to limit it's own power? Passing the C4 will limit even Eelco's power. Imagine every single maintainer not being able to merge their own commits. The way lethalman handled this PR of mine is exactly the correct way [3] except there should have been no dialogue or at least reducing as much upfront consensus as possible - you can't fight amdahl's law, and it's just going to get worse the larger nix gets. Indeed, this is exactly what @globin should have done, cause I would have fixed it if it was broken, why? Cause that bit of code is in my L1 cache not @globin's. If for example I broke it and didn't fix it again, revert my commit. Simple. It's much less trouble on @globin to JUST check a correct patch and merge it asap. I repeat, you can't fight amdahl's law, and it's just going to get worse the larger nix gets. kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] rustc failure on nix only?
On 31 Aug 2016 02:01, "Matthias Beyer" wrote: > We fixed that in [650] which allowed beta to fail and we reverted that > patch in [655] as beta was updated and builds now. okay, thanks. Seems like the new parsers for semver were throwing a tantrum? I'll take a closer look soon. Cheers! /sjm P.S. take a look at replacing make with nix. You can get some fancy lazy builds going. It's really quite a fun way to structure code. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] rustc failure on nix only?
Hi Matthias Beyer, Have you had any headway on this error in your imag application? error: failed to load source for a dependency on `...` https://botbot.me/mozilla/rust/2016-08-22/?msg=71719353&page=9 kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
On Tue, Aug 30, 2016 at 8:02 AM, Shea Levy wrote: > globin missed the fact that the naming convention is messing up the > lowPrio logic, and your original PR had nothing to do with that. If rust > were named properly, your fix would be wrong. What is the exact naming scheme that rust should adopt? I will make a pull request to fix this. > Even in this case where > your fix is harmless (which globin reasonably missed), it doesn't > actually fix your issue and in the event that the rust naming is fixed > it would be harmful then. Secondly, I want to test this harmful aspect. What is the expected harmful behaviour if I follow the steps to reproduce i.e.: correctly name each rust and remove lowprio? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Including "beta" or "unstable" identifiers in package names?
Trying to understand your email: in development/compilers/rust beta.nix: current behaviour: the name "beta" is already part of the version -> see "shortVersion" "... rustc = callPackage ./rustc.nix { shortVersion = "beta-2016-08-17"; ..." https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/rust/beta.nix#L5-L6 in head.nix current behaviour: the name "master" is already part of the version -> see "shortVersion" "... rustc = callPackage ./rustc.nix { shortVersion = "master-1.13.0"; ..." https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/rust/head.nix#L5-L6 I don't understand: "IMO the 'beta' and 'master' is part of the version, not the package name, and so if it exists at all it should be part of the version string;" as it quite clearly is part of the "shortVersion" ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
rust is a fast moving target, I don't want too much breakage. Recently upstream decided to shove experimental features into nightly releases (ie the allocator we're using which broke our build), this would cause huge breakage and annoyance ameliorating issues. It's better to keep lockstep with Rust. Once those experimental features *eventually* hit stable then I'll breathe a sigh of relief. Till then, it's the march of wicked. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Sorry guys for showing my anger. Shea, you're doing a great job and I rely on your great work all the time. Thanks ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Okay, then I'm absolutely boggled as to why each and every time I update I have recompile rustBeta.rustc then rustUnstable.rustc. I've literally been using nix-build ... -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/125089b6bd360c82cf986d8cc9b17fc2e8ac.tar.gz for more than a month. That is the last working revision of Rust. I really should get sleep. I'm at my wits end. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
I just want this issue resolved. Every time I update / upgrade I recompile rustBeta then rustUnstable and it results in 1/2 day lost. This has happened frequently, recently as rustUnstable and rustBeta have been broken for a long time. (ie days have been lost finding working revs then compiling rust) If the lowprio removal doesn't solve this then how can I get it such that when I issue a `nixos-rebuild --upgrade switch` and my configuration.nix contains `rustUnstable.rustc` downloads these binaries http://hydra.nixos.org/job/nixos/release-16.03/nixpkgs.rustUnstable.rustc.x86_64-linux. What exactly does lowprio do? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
> adversely affect nix-env users in that case. How? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
1+1=2 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Why is it like pulling teeth getting a simple pull request into nixpkgs? Something is _very_very_ broken people. Can we please fix this asap? No I don't want to hear bullshit reasons about keeping X Y Z maintainer's powers. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
in the beginning Shea... where it says "Goals" ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
On Tue, Aug 30, 2016 at 7:36 AM, Shea Levy wrote: > Perhaps they are not random if you know their origin or justification, > neither is given at the link though. Backtrack? Are you kidding me? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
*me ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Not justified in the link? Are you kidding link? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
Sigh, random rules? Are you kidding me? Nevermind ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
due to multiple causes, but the latest straw on the camel's back is this pull request: https://github.com/NixOS/nixpkgs/pull/18101 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
http://rfc.zeromq.org/spec:42/C4/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] 6 month C4 adoption period
Dear Nixers, Please may we start a C4 adoption period of 6 months then do a review after this? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] typed nix
per chance, is there work underway to make nix a typed language? kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Cross development for STM32
I'd really like to see a simple nix way to retarget derivations. So maybe `buildRustPackageForAndroid` or `buildRustPackageForSTM32`. or maybe buildRustPackage rec { name = "habitat-${version}"; version = "0.8.0"; target = "android"; ... } kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Generating nixos-compatible binaries? And bootstrapped packages.
Have a look at patchelf kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardening flags enabled by default
Huge kudos for this work guys! Excellent job and much appreciated! kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] bring into scope only required deps
Hello, The fractalide repository consists of N components that can be combined in Z different ways, called a subnet. A subnet represents a normal application you are used to executing. one tells the repository to build Z subnet via this command: $ nix-build [other args] --argstr subnet test_sjm or $ nix-build [other args] --argstr subnet app_growtest etc Each component in a subnet connects with another component via a capnproto contract. A special component called contract_lookup has knowledge about the file system path of every contract. This knowledge is needed for the component oriented language to do "dynamic" lookups. example: [1] notice the 'maths_boolean:(boolean=true)' that is a contract called `maths_boolean` [2] Problem: the component contract_lookup [3] is dependent on all contracts [4]. When distributing the graph of components I want contract_lookup to only see contracts that are used within the Z subnet. I don't want contract_lookup to be dependent on every single contracts, because as the system grows and more contracts are added it would mean I have to distribute every contract for Z subnet. This is mental. Is there a way I can somehow query the top level rust program [5] and ask for only those contracts that are being used, then pass it into the contract_lookup which will write the rust hashmap? [3] (currently the rustUnstable.rustc on nixos-unstable is broken so you'll need to use $ nix-build --argstr debug true --argstr subnet test_sjm -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/125089b6bd360c82cf986d8cc9b17fc2e8ac.tar.gz ) Kind regards Stewart [1] https://github.com/fractalide/fractalide/blob/master/components/test/sjm/default.nix#L9 [2] https://github.com/fractalide/fractalide/blob/master/contracts/maths/boolean/contract.capnp [3] https://github.com/fractalide/fractalide/blob/master/support/contract_lookup/default.nix#L11-L13 [4] https://github.com/fractalide/fractalide/blob/master/contracts/default.nix [5] https://github.com/fractalide/fractalide/blob/master/support/vm/default.nix ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Troubleshooting boot failures & rollbacks
Hi, try using `$ nixos-rebuild boot` to test out your system first. $ man nixos-rebuild ... boot Build the new configuration and make it the boot default (as with nixos-rebuild switch), but do not activate it. That is, the system continues to run the previous configuration until the next reboot. test Build and activate the new configuration, but do not add it to the GRUB boot menu. Thus, if you reboot the system (or if it crashes), you will automatically revert to the default configuration (i.e. the configuration resulting from the last call to nixos-rebuild switch or nixos-rebuild boot). ... kr/sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Windows updates
Aye, couldn't agree more with you. Kudos Eelco + contributors. On 7 Aug 2016 06:44, "zimbatm" wrote: > I'm staring at a spinning update indicator right now and all I wanted to > do is play a game on Windows. My wife purposely ignores the Windows updates > because it never happens at a convenient time. > > So just to say that NixOS is awesome. Making updates is a background > activity that doesn't need to affect the currently running system. And if > it does, the changes are more or less instant. Meaning people would be more > inclined to update as well. > > Thanks Eelco and contributors for this great system :) > > ___ > 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] Too many open issues
On 26 Jul 2016 22:22, "Wout Mertens" wrote: > Anybody up for C4? Finally some sanity! Yes! (FFS!) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix as a library
Hmm on second thoughts, it's probably best to expose a nix-repl... it would be much more powerful. Thanks for than Vladimir! The user interface (ie compile button, whatever) could just write strings directly into the repl then linefeed, or you could just type it yourself. This would simplify things quite a lot actually. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix as a library
Ohh exciting, I'll investigate :-) On Sun, Jul 10, 2016 at 12:25 AM, Vladimír Čunát wrote: > I think there are some APIs, but without guarantees of their stability: > libnixexpr.so libnixformat.so libnixmain.so libnixstore.so libnixutil.so ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix as a library
Yeah, doable, but undesirable. Anyway, there is no API, i'll roll with calling executables. cheers Vladimír and zimbatm. On Sat, Jul 9, 2016 at 8:53 PM, Vladimír Čunát wrote: > Communication with a single instance of nix-repl might be more efficient > for some use cases, as it can retain evaluated sub-expressions between > individual "commands". ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix as a library
Hmm okay, I have a use case then. We're building a data flow editor in fractalide. As component oriented styles of programming makes the concept of data flowing through a system to be a first class citizen, the editor merely enhances this data flow manipulation to a few points and clicks. It's what allows for trivial reusability of components. Now if we couldn't load a nix library we'd have to make every single component a dependency of this editor. This is undesirable, as the build time would be too long. Besides, Fractalide is designed to have 1000s of components and you'll only compile what you need per app. It's much better to make this hypothetical nix library be the only dependency of the editor, thus when you need/create a (new) component in the editor, the editor fires up the component build via the nix library. The editor would have adequate intelligence to libload once the build succeeds, or allow you to debug the code. (vapourware) This way, we wouldn't have to 'pop' fractalide out of nix to allow such dynamic editor behaviour, but instead we'd completely embrace nix. Why a C interface? Well most languages can handle the C ABI, so it would be useful, otherwise only C++ apps could load the library. Besides, we're using Rust and that won't interact with the C++ ABI. (C++ ABI is a complete train smash). Probably http://www.swig.org could do a nice enough job of providing an interface to whatever language needs access to nix functionality. Would be great to hear if anyone else has this use case. On 9 Jul 2016 05:52, "Vladimír Čunát" wrote: > On 07/08/2016 12:53 PM, stewart mackenzie wrote: > > Are there any plans to make nix's functionality into a library so that > > a programmer could include these libraries and affect change to the > > system via a program they made? > > > > (keeping a C ABI so that it'll work with libffi) > > There's been some discussion on that point already, but AFAIK noone has > produced a use case where using C interface would be significantly > superior to using CLI interface (which has to be maintained reasonably > stable anyway). > > --Vladimir > > > > ___ > 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] nix as a library
Are there any plans to make nix's functionality into a library so that a programmer could include these libraries and affect change to the system via a program they made? (keeping a C ABI so that it'll work with libffi) kind regards /sjm ___ 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
On 20 Jun 2016 17:53, "Domen Kožar" wrote: > I do agree it's additional work, but it's better than current state where we all maintain our Hydra from carefully picked commits and that's REALLY some additional work. Completely agree, it's kind of annoying going through the commits determining which one is good. Once selected you're hesitant to move to a more recent commit as it could blow up. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stackage Support Will Be Discontinued
ohh first time I've seen such gauntlet throwing. Passionate Haskellers! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wordpress
I would switch in a heartbeat, using ubuntu, docker+virtualbox(inside virtualbox), virtualbox screen size issues, something called docker-machine I have to install manually into /usr/local/bin/ is not fun, and I'm actively suppressing grumpiness ... it's times like this I really appreciate nix. My time to help out contributing beyond testing is severely limited. I foresee this wordpress project lingering for 6~8 months. Thereafter we'll be developing a different solution completely based on Rust and Nix. I think I'll pause on ubuntu to try out your approach. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wordpress
Naa time critical nature, just decided to spin up an ubuntu virtualbox. Ah I recognize the email address from the code you wrote :-) It would seem it's very centered around deploying stock releases not amenable for developing on wordpress. But I didn't get that far. Is there a faster route? On 10 Jun 2016 02:06, "Joachim Schiele" wrote: > got it working? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wordpress
Ah I see this: https://nixos.org/wiki/Wordpress I'll need to override the src of wordpress with my own version of wordpress. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] wordpress
Hi, I see there's a wordpress package: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-servers/apache-httpd/wordpress.nix There are no available wordpress attributes. How do I install wordpress? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 6b9c67: elm: 0.16.0 -> 0.17.0 (#15383)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 6b9c67333fe62c38f1231dd5339b776c7c3d7172 https://github.com/NixOS/nixpkgs/commit/6b9c67333fe62c38f1231dd5339b776c7c3d7172 Author: Stewart Mackenzie Date: 2016-05-11 (Wed, 11 May 2016) Changed paths: M pkgs/development/compilers/elm/packages/elm-compiler.nix M pkgs/development/compilers/elm/packages/elm-make.nix M pkgs/development/compilers/elm/packages/elm-package.nix M pkgs/development/compilers/elm/packages/elm-reactor-elm.nix M pkgs/development/compilers/elm/packages/elm-reactor.nix M pkgs/development/compilers/elm/packages/elm-repl.nix M pkgs/development/compilers/elm/packages/release.nix Log Message: --- elm: 0.16.0 -> 0.17.0 (#15383) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Nixbot - a little helper for pull requests
Hi Louis, I really hope the community rolls this out! Great work! /sjm On Fri, May 6, 2016 at 12:27 PM, Louis Taylor wrote: > code talks a lot louder than words: > > https://github.com/kragniz/nixbot ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Incremental recompilation
Isn't the simplest solution this: declare an output `outputs = ["out" "cache"];` now the word cache is hardcoded to create a directory /tmp/${derivation-name}-cache/ this name doesn't change. Now, in your derivation you can set the build tool (via env var if it supports that) to use this cache folder as a place to store the build artifacts. You may then copy the final build product from `$cache` to `$out` at some in the `installPhase`. The last thing about `cache` is that it is _not_ deleted after the derivation builds. kr /sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Incremental recompilation
It would be great to deploy the build product without the caches. Preferably expose the API as part of mkDerivation. This way I could pass in a 'develop' flag and if true, switch the cache on, else leave it off. Now I'll be able to deploy without caches. i.e.: if develop == true then cache = true else ""; IMHO, incremental compilation is a strong boon for nix adoption. It is the only serious issue I can see which prevents Nix being a Make replacement. Many projects start with a Make file, right away there is a dependency. Why not just install Nix instead of Make as your project dependency, immediately your project gets access to needed deps and do a whole bunch of really powerful things to your source code. We use Nix as a Make replacement, and I'm hooked to the point where I'm able to endure no IR. So, this IR feature will upgrade Nix to a class A drug, without the hazardous effects, from where I'm sitting. /sjm ___ 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
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
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
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
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
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] break purity
Hi Oliver, Here is a minimal example stripped of all the other crap: https://github.com/fractalide/recompilation Cheers! /sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] break purity
Okay, I'm having a few problems implementing this, if you wouldn't mind taking a look at this please: This is the package level default.nix which calls `buildFractalideComponent`: http://nixpaste.lbr.uno/ZTwRzV0-?nix Typically found here: https://github.com/fractalide/fractalide/blob/master/components/drop/ip/default.nix Here is the implementation of `buildFractalideComponent.nix`: http://nixpaste.lbr.uno/GmbsNjmk?nix Found here: https://github.com/fractalide/fractalide/blob/master/build-support/buildFractalideComponent.nix Here's my error message: [stewart@rivergod:~/dev/fractalide/fractalide]$ nix-build --argstr debug true -A components.drop_ip error: value is a function while a set was expected, at /home/stewart/dev/fractalide/fractalide/components/drop/ip/default.nix:15:21 (use ‘--show-trace’ to show detailed location information) The error arises on the last line of default.nix /sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] haskell structure for all of nixpkgs
Every time I come into contact with Peter Simon's work on Haskell I find myself growing green with envy. This approach seems to be a much better way of structuring nixpkgs in general. Now closure-size, a monumental job was undertaken successfully, what's the feasibility of implementing the Haskell approach across the entire nixpkgs. How does one even start thinking about this? Is it even worth it? /sjm ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev