Hash prefetching powered by nurl with support for cargoHash and vendorHash
Dependency inference for Rust, Go, and Python projects
Interactive prompts with fuzzy tab completions
License detection
Supported builders
stdenv.mkDerivation
buildRustPackage
buildPythonApplication and buildPythonPackage
buildGoModule
Supported fetchers
fetchCrate
fetchFromGitHub
fetchFromGitLab
fetchFromGitea
fetchPypi
All other fetchers supported by nurl are also supported, you just have to specify the tags manually
Usage
Usage: nix-init [OPTIONS] [OUTPUT]
Arguments:
[OUTPUT] The path or directory to output the generated file to
Options:
-u, --url <URL> Specify the URL
-n, --nixpkgs <NIXPKGS> Path to nixpkgs (in nix)
-c, --config <CONFIG> Specify the config file
-h, --help Print help
-V, --version Print version
nix-init generates callPackage friendly files which can be used in flakes. I don’t plan to support anything specific to flakes since the flake format doesn’t correspond to one single package, which nix-init tries to generate. Also note that currently nix-init only supports non-local projects (src = fetchFromGitHub ... instead of src = ./.), so it might be more helpful fore NUR-like multi-package flakes.
If you are looking for something to reduce the boilerplate of creating a new flake, check out nix flake init or nix-template. If you are looking for a common UI to build something using flakes, check out dream2nix which also has a simple template that can be used with nix flake init.
i’m of course going try it out myself, but for the curious: for the similar derivation/package declaration functionality, how does it compares to nix-template? for my quick view, yours seem to have greater automation with dependency inference.
I only learned about nix-template recently so correct me if I’m wrong.
In terms of package declaration functionally, it looks like nix-template’s features are more dependent on the selected template and fetcher, I didn’t get any python dependencies when I chose to use black from github instead of pypi. nix-init also has more features in this aspect, e.g. detecting the language/build system so you don’t have to pick the template yourself, dependency inference for rust dependencies, automatically filling in cargoHash and vendorHash, changelogs, and mixing buildPythonApplication or mkDerivation with cargoSetupHook and cargoDeps.
Something nix-template does that nix-init doesn’t is nixpkgs integration - it automatically creates directories in nixpkgs based on the template and tells you how to add the package to top level. This is something I don’t plan to implement for nix-init unless nixpkgs change its directory structure (i.e. RFC140). nix-template also supports creating (plain text) templates without a project, which can be helpful to reduce some boilerplate.
Something fundamentally different is that nix-init is interactive and guesses stuff like the template you want to use and has fzf-like tab completion (with rustyline and skim), and nix-template has support for non-package templates like NixOS modules and flakes.
Some smaller differences are that nix-template has a Qt template which nix-init doesn’t have, and nix-init has a wider support of fetchers
Damn this is slick! We need this kind of thing built into Nix (or advertised via Nix, wrapping a flake, like nix bundle). (Guix has something like this in guix import, as you may know.)
Glad you liked it! I doubt this will make its way into nix, but it would be nice to have a more scriptable (instead of plain text) nix flake init that can work like guix import.
support for RFC 140 pkgs/by-name (RFC, implementation). Thanks @infinisil and the Nixpkgs Architecture Team for working on this amazing feature in nixpkgs! A brand new commit option is added for this to commit the changes if it looks like it is by-name.
It would be good to generate the file but from a compressed file found in the version releases, so that it is not necessary to compile the whole binary
