lorri | nickel | |
---|---|---|
6 | 46 | |
998 | 2,153 | |
- | 2.1% | |
0.0 | 9.5 | |
almost 2 years ago | about 5 hours ago | |
Rust | Rust | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lorri
-
NixOS + Haskell best practices circa March 2023
lorri
- Lorri: Project's Nix-Env
-
niv, naersk, napalm: moving on
And how does niv compare to https://github.com/target/lorri
-
A treatise on Nix
Yes, you can "hold on", it's called gcroots. There's lorri which you can also use to defer the tediousness of managing the gcroots to a daemon.
-
Per process memory and CPU usage control
Not that I know of but if you are having trouble with rebuilding and running out of memory, maybe the solution would be to cache the builds locally? You could use lorri to cache your development builds (https://github.com/target/lorri).
-
NixOS Linux
> Using a special command (nix-shell) whenever I needed to do development things (e.g. Rust builds) was not my idea of fun.
Funny you should mention that, because that's exactly what got me using Nix everywhere :). I've always hated installing tools and libraries globally—what if I need a different version for a future project?—so I like tools that sandbox as much as possible like virtualenv, cargo, cabal... etc. But these tools are all language-specific and have their own limitations (especially around native libraries and dependencies written in other languages).
nix-shell gives me the equivalent of virtualenv that works for everything. I can have a single sandboxed environment even if my project uses a bunch of different languages and I can manage everything in a reproducible, low-overhead fashion. No more worrying about making a mess by installing tools or packages globally.
Then, once I got really used to that, I spent some time setting up direnv[1] and lorri[2]—both of which are themselves managed with Nix, of course!—so that my environment gets automatically configured as soon as I enter a project directory without needing to call nix-shell explicitly. To be honest, the experience is still a bit rough, but it works well enough day-to-day that I have my reproducible sandbox cake and eat it in an mostly frictionless way too :).
[1]: https://direnv.net/
[2]: https://github.com/target/lorri
nickel
-
Nix – A One Pager
So, its key features are:
1. domain-specific: designed for conveniently creating and composing derivations. This reason alone already justifies a new language, or an embedded domain-specific language (such as the Guile/Scheme for guix), or a mix of both (Starlark, the build language of Bazel embedded in a restricted Python-variant).
2. purely functional: this ties well into the philosophical backing of Nix the package manager, which aims to be purely functional, also known as hermeticity in other build systems (Bazel).
3. lazily evaluated: similar to other build systems (including Bazel), so that you can build only what you need on demand.
4. dynamically typed: this one is controversial. Being dynamically typed—in other words, not developing a type system—gets Nix out of the door first. But users often complain about the lack of proper types and modularity. There are experiments to address this, such as Nickel (https://github.com/tweag/nickel).
It is understandable that a one-pager may not have space for the whys.
-
10 Ways for Kubernetes Declarative Configuration Management
Nickel:Nickel is a straightforward configuration language aimed at automatically generating static configuration files. Essentially, it's akin to JSON with the addition of functions and types.
-
Show HN: Togomak – declarative pipeline orchestrator based on HCL and Terraform
Also look at nickel which is an evolution of nix. It's my favorite in this space.
nickel-lang.org
https://github.com/tweag/nickel
- Show HN: Flake schemas – teaching Nix about your flake outputs
-
What config format do you prefer?
Or this https://github.com/tweag/nickel
-
Nickel 1.0
Nickel is a programming language. While HCL is just a configuration format, so not really comparable.
Here's a comparison with similar tools: https://github.com/tweag/nickel#comparison
-
Announcing Nickel 1.0, a configuration language written in (and usable from) Rust
As for 'providence', I suppose you meant provenance :) it's been delayed because this was less critical for 1.0 to decide on or to implement (as it: it doesn't break backward compatibility in any way to add this feature in the short term), but this is very much on the roadmap: Issue #235. That's a must-have in a language with merging like Nickel.
-
Rewrite it in Rust: Kubernetes
Have you considered using a different language for templating? this could be a BIG selling point. Some good ones are cue-lang (though I haven't seen support for rust), kcl or nickel-lang.
- Nickel v1.0.0
- Design rationale for the Nickel configuration language
What are some alternatives?
direnv - unclutter your .profile
rnix-lsp - WIP Language Server for Nix! [maintainer=@aaronjanse]
nix - Nix, the purely functional package manager
nixos - My NixOS Configurations
nix-direnv - A fast, persistent use_nix/use_flake implementation for direnv [maintainer=@Mic92 / @bbenne10]
nix-gui - Use NixOS Without Coding
nixops - NixOps is a tool for deploying to NixOS machines in a network or cloud.
nix-doc - An interactive Nix documentation tool providing a CLI for function search, a Nix plugin for docs in the REPL, and a ctags implementation for Nix script
dotfiles - i3 + Plasma: using the i3 window manager on the top of KDE Plasma and other dotfiles, configurations, scripts, workarounds and practises from my Debian Sid machines.
AppImageKit - Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
patchelf - A small utility to modify the dynamic linker and RPATH of ELF executables