openocd
haskell-te
openocd | haskell-te | |
---|---|---|
1 | 1 | |
4 | 5 | |
- | - | |
5.9 | 10.0 | |
10 months ago | over 4 years ago | |
C | Nix | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
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.
openocd
-
NixOS RFC 136 accepted: A plan to stabilize the new CLI and Flakes incrementally
I also really like flakes. I know they are still experimental today - though hopefully that'll improve with this RFC - but they make it trivial to have an out of tree package. For example I just recently created a flake for a vendor OpenOCD fork [0] - and now I can reference that in my home-manager config or from some other project.
[0] - https://github.com/benpye/openocd/blob/mrs-2023-08-07/defaul...
haskell-te
-
NixOS RFC 136 accepted: A plan to stabilize the new CLI and Flakes incrementally
Yes, to get Nixpkgs it's much faster to use `fetchTarball`.
You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`.
Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... )
Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )
What are some alternatives?
repology-updater - Repology backend service to update repository and package data
mvn2nix - Easily package your Maven Java application with the Nix package manager.
nixpkgs - Nix Packages collection & NixOS
rfcs - The Nix community RFCs
nixos-infect - [GPLv3+] install nixos over the existing OS in a DigitalOcean droplet (and others with minor modifications)
nixos-generators - Collection of image builders [maintainer=@Lassulus]
nix-helpers - Mirror of http://chriswarbo.net/git/nix-helpers.git
nixos-anywhere - install nixos everywhere via ssh [maintainer=@numtide]