I read the entire thing and I’m not sure what it is doing or what we should be doing.
The only command that’s in there is: nix flake init -t github:nickel-lang/organist but that’s I guess how you setup an organist project, not how you use it? Then you use it regularly with nix develop?
Update: I think if you read the README here, it becomes clear: https://github.com/nickel-lang/organist Still not really clear whether or how it’ll fill many of my development needs.
Ncl
I browsed Nickel documentation previously but still, constructs like this leave me rather mystified:
services.minio = nix-s%"
%{organist.import_nix "nixpkgs#minio"}/bin/minio server --address :9000 ./.minio-data
"%
What is happening here with the %s?
I’d say in general that Nickel may be a great idea and it looks less offputting than Nixlang but it’s still very far off from something a large audience of people can use.
Recently I saw Garn which is a “Typescript eats the entire world” approach to this problem. I’m also very sceptical of it as an abstraction layer, but the choice of language does look like it could be a winner. It reminds me a bit of CDK/Typescript which is a weird imperative/declarative hybrid alternative to the standard terrible Devops ways of defining infrastructure.
My impressions as well. I’m not sure if this competes with devenv, devbox, and others, or is some completely different thing. If former, what does it bring over other tools.
Similar thoughts. Even as a Nix user I’m confused about some of the syntax I’m unfamiliar with, and generally about what Organist is trying to be.
If it’s a layer above Nix flakes dev shell configuration like some of the other projects, it seems like a hard sell as if you can do Nickel… you probably can do Nix already, and introducing an extra layer is neither here or there. If you go json/yaml it will be dumbed down but easier to consume for non-nixers, and if you go Nix - you are 100% seamless with Nix.
BTW. I’m causally lurking into Nickel and I’m still confused w.r.t level of interoperability with Nix. Nickel presents itself like a Nix-like “configuration language”, which means … it can’t really do some of the things Nix do? Or can it? Can it transpile to Nix or something?
My take is that yes it’s competing with those tools, but in a (nearly) native nix way, nearly as it depends on Nickel tooling, but the generated flake pulls that in automatically so there’s nothing else to install.
At work I am using Devenv mostly for process support (which ironically I don’t need any more) and it fits the bill, but IS two things to install before team members can start developing (plus direnv). This would only be one thing to install.
At home I run NixOS and just use a flake for my dependencies but that doesn’t launch any services so I am kind of keen on using organist if I ever need that.
My take is that yes it’s competing with those tools, but in a (nearly) native nix way, nearly as it depends on Nickel tooling, but the generated flake pulls that in automatically so there’s nothing else to install.
It’s very cool that this works so you can have your flake contents defined in some other language entirely and don’t have to think about it (if it works).
Okay, I think I get it. This is for IDEs – integrated development environments – specifically, where various background services require orchestration.
And, to be honest, that sort of environment is inherently more complex than one where the code editor stands alone and the code’s functionality is hermetically testable. I don’t think Organist is bad, but I’m skeptical of a setup which requires it.
At the end of the day, if it fits into a Nix flake, then I suppose I don’t care; I don’t have to actually know what’s inside a flake in order to use it. But I can’t imagine using this instead of a ten-line bash script which runs git pull, hooks direnv, and loads my SSH keys.
specifically, where various background services require orchestration
I’ve had to read comments going in all directions with the nix services RFC and then to see something like this just pull that out of a hat (admittedly in a butchered way) is kinda amazing.
It’s not just IDEs. Any serious development is going to need a database etc. for which people now are referred to “use a container”.
What is necessary is to have all common services defined somewhere because I’m not going to figure out the correct commands to initialize and start Postgres every time from scratch.
I read the entire thing and I’m not sure what it is doing or what we should be doing.
The only command that’s in there is:
nix flake init -t github:nickel-lang/organistbut that’s I guess how you setup an organist project, not how you use it? Then you use it regularly withnix develop?Update: I think if you read the README here, it becomes clear: https://github.com/nickel-lang/organist Still not really clear whether or how it’ll fill many of my development needs.
NclI browsed Nickel documentation previously but still, constructs like this leave me rather mystified:
What is happening here with the
%s?I’d say in general that Nickel may be a great idea and it looks less offputting than Nixlang but it’s still very far off from something a large audience of people can use.
Recently I saw Garn which is a “Typescript eats the entire world” approach to this problem. I’m also very sceptical of it as an abstraction layer, but the choice of language does look like it could be a winner. It reminds me a bit of CDK/Typescript which is a weird imperative/declarative hybrid alternative to the standard terrible Devops ways of defining infrastructure.
My impressions as well. I’m not sure if this competes with devenv, devbox, and others, or is some completely different thing. If former, what does it bring over other tools.
Similar thoughts. Even as a Nix user I’m confused about some of the syntax I’m unfamiliar with, and generally about what Organist is trying to be.
If it’s a layer above Nix flakes dev shell configuration like some of the other projects, it seems like a hard sell as if you can do Nickel… you probably can do Nix already, and introducing an extra layer is neither here or there. If you go json/yaml it will be dumbed down but easier to consume for non-nixers, and if you go Nix - you are 100% seamless with Nix.
BTW. I’m causally lurking into Nickel and I’m still confused w.r.t level of interoperability with Nix. Nickel presents itself like a Nix-like “configuration language”, which means … it can’t really do some of the things Nix do? Or can it? Can it transpile to Nix or something?
My take is that yes it’s competing with those tools, but in a (nearly) native nix way, nearly as it depends on Nickel tooling, but the generated flake pulls that in automatically so there’s nothing else to install.
At work I am using Devenv mostly for process support (which ironically I don’t need any more) and it fits the bill, but IS two things to install before team members can start developing (plus direnv). This would only be one thing to install.
At home I run NixOS and just use a flake for my dependencies but that doesn’t launch any services so I am kind of keen on using organist if I ever need that.
It’s very cool that this works so you can have your flake contents defined in some other language entirely and don’t have to think about it (if it works).
You can use Devenv as a
mkShellreplacement when working with Nix Flakes, so you do not need to install anything manually.One of the article’s links is to Organist’s README – How does this differ from {insert your favorite tool} ?. In summary, Organist’s closest competitor is Devenv, and its main advantage is the consistency and power of the Nickel language.
Okay, I think I get it. This is for IDEs – integrated development environments – specifically, where various background services require orchestration.
And, to be honest, that sort of environment is inherently more complex than one where the code editor stands alone and the code’s functionality is hermetically testable. I don’t think Organist is bad, but I’m skeptical of a setup which requires it.
At the end of the day, if it fits into a Nix flake, then I suppose I don’t care; I don’t have to actually know what’s inside a flake in order to use it. But I can’t imagine using this instead of a ten-line bash script which runs
git pull, hooks direnv, and loads my SSH keys.I’ve had to read comments going in all directions with the nix services RFC and then to see something like this just pull that out of a hat (admittedly in a butchered way) is kinda amazing.
It’s not just IDEs. Any serious development is going to need a database etc. for which people now are referred to “use a container”. What is necessary is to have all common services defined somewhere because I’m not going to figure out the correct commands to initialize and start Postgres every time from scratch.
Nickel is such a cool little configuration language. I wish it were offered in library form so I I didn’t have to lose types to JSON.
[Comment removed by author]