nix-cde
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.
bundlers
-
The Magic Nix Cache
- the caching works across branches, so for example merging a feature branch to master, if nothing changes the build on master will be very quick
I created something similar to nix-cache for gitlab, but I had to create a dedicated runner running NixOS.
If I could use NixOS for deployment, at that point I would just point the same binary cache to the machine and use the same derivation to build the app. Because the app was already build by CI, it would just download the compiled version. No need for artifactory or similar. In that scenario (you using poetry) you probably would just use poetry2nix to generate the application.
If the OS is not NixOS, but you still want to deploy via nix, then IMO this[2] looks interesting, basically it packages everything in self extracting archive. That you can extract and then run the app.
Other alternatives are these bundlers[3], which includes building toArx (works in a way similar to the previous one but pretends everything is in a single file), RPM, DEB, docker (you would have more control over it if you would use the code directly instead of a bundler though)
And the last option (probably the most obvious one) is that you can simply just use the tool to build the package. Since you're using poetry, then you can generate a wheel from it.
[1] https://github.com/takeda/nix-cde/blob/master/contrib/gitlab...
[2] https://github.com/Ninlives/relocatable.nix
[3] https://github.com/NixOS/bundlers/blob/master/flake.nix
-
After 20 years are developers now ready for Nix?
We've seen the opposite. New package managers are built with a much better understanding of the problem space because of Nix and sometimes explicitly taking ideas and concepts. This results in those new systems being far more compatible and easily integrated with Nix itself. Consider the iteration towards better and better locking in python + Node. Consider Rust/Cargo.
There has also been sharing of ideas and collaboration between things us and bazel/buck/spack/etc. I think it is clear that we are all moving towards a similar end state, that often looks very much like Nix, or a re-invention of it.
For things like OCI, Nix predates it, but we should start to re-use the standard. The Tvix group is exploring this and I'd suspect our sandboxing will be OCI at some point. For outputs; we make it easy to convert a Nix package into an equivalent container. Things like flatpack,AppImage,Snap should also be easy for people to output (i'm trying to collect these "transformers"/"bundlers" here: https://github.com/NixOS/bundlers).
-
Nixpacks takes a source directory and produces an OCI compliant image
Nix 3 has a dead simple, builtin CLI frontend for built packages: https://nixos.org/manual/nix/unstable/command-ref/new-cli/ni...
It uses dockerTools: https://github.com/NixOS/bundlers/blob/master/flake.nix
maybe a bundler can be added that uses OCI tools, thus providing such a wrapper and giving a nice CLI for it
nix-cde
-
The Magic Nix Cache
This is what I'm using with gitlab: https://github.com/takeda/nix-cde/blob/master/contrib/gitlab...
-
Using Nix as an alternative to dev containers in VScode.
I myself use https://github.com/takeda/nix-cde it just wraps other projects in an opinionated way and contains the boiler plate that I would normally use otherwise.
-
As if there weren't enough packaging tools already: mitsuhiko/rye: an experimental alternative to poetry/pip/pipenv/venv/virtualenv/pdm/hatch/…
There's a project that does this with using Nix: https://github.com/takeda/nix-cde (this is a wrapper around https://github.com/nix-community/poetry2nix)
- Docker multi-stage build with Poetry
-
Python 3.11 delivers.
I personally use this: https://github.com/takeda/nix-cde it has the benefit of a reproducible build environment, but unfortunately anything involving Nix has a steep learning curve.
-
The perfect way to handle project-specific developer configs
I use this myself: https://github.com/takeda/nix-cde
-
Asdf – the language tool version manager
I don't use NixOS myself, but have Nix installed on my Mac, and it seems to provide all functionality of package or version managers I needed.
I think though it is more complex because it is a programming language that provides this functionality instead of purpose build tool like asdf.
For my needs I created a framework for development: https://github.com/takeda/nix-cde to avoid cruft of including the same things over and over in my projects.
-
Use `Python -m Pip`
Not an OP, but I became a big fan of using poetry for managing dependencies. For managing python version I started using Nix package manager. It allows to describe all dependencies via code, but with time that code became a boilerplate, so I created this: https://github.com/takeda/nix-cde
It works very well for me so far.
What are some alternatives?
hasql-interpolate
relocatable.nix - A nix bundler that produces relocatable deployment script for nix store paths.
aws-lambda-python-runtime-interface-client
nixpkgs - Nix Packages collection & NixOS
nixml - NIX + YAML for easy to use reproducible environments
stage0 - A set of minimal dependency bootstrap binaries
globus-timer-cli - CLI for interacting with the Timer API
m1-terraform-provider-helper - CLI to support with downloading and compiling terraform providers for Mac with M1 chip
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
sigstore-python - A Sigstore client for Python
devenv - Fast, Declarative, Reproducible, and Composable Developer Environments