nix-cde
globus-timer-cli
nix-cde | globus-timer-cli | |
---|---|---|
9 | 1 | |
29 | 1 | |
- | - | |
6.4 | 5.4 | |
5 days ago | 8 months ago | |
Nix | Python | |
MIT License | Apache License 2.0 |
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.
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.
globus-timer-cli
-
Use `Python -m Pip`
It has only recently sunk in for me that, with the latest versions, Pip is not a tool for maintaining an environment and list of dependencies (where you'd have a lockfile, for example). Instead, it is an interface to…
1. Download packages from PyPi (or a different repository that provides the same interface)
2. Read the pyproject.toml file to find the build backend to use, and then install that.
3. Call the build backend to actually do the installation. This can be Poetry, Setuptools, Flit, or something else.
Pipenv is another such interface.
PEP 517 (https://peps.python.org/pep-0517/) created pyproject.toml and defined the API that build backends follow. That API includes a way for the build backend to tell Pip (or Pipenv, etc.) what dependencies to install. For systems that have a lockfile (like Pipenv), that could be a list of packages with explicit versions.
PIP 660 extended PEP 517, defining a standard way to have "editable installs". In other words, a way to support `pip install -e package`, or even `pip install -e .`.
The above is all my understanding, which is not at all authoritative!
It's worth checking out the list of packaging-related PEPs: https://peps.python.org/topic/packaging/ It's worth reading PEPs 518 and 621.
As an example, here's a Python package that uses Poetry: https://github.com/globus/globus-timer-cli It works perfectly fine with Pip, because Pip sees (via `pyproject.toml`) that it needs to pull in Poetry, and call it to do the actual install.
Here's an older repo of mine, where I've just started to learn about the transition: https://github.com/stanford-rc/mais-apis-python/blob/main/py... In this case, I could delete `pyproject.toml` entirely, Pip would see the `setup.py` file, and understand to use Setuptools. This was me when I was just starting to learn about the transition.
Finally, here's a newer repo of mine, where I've ditched setup.py (and _almost_ ditched setup.cfg) entirely: https://github.com/stanford-rc/globus-group-manager I'm still using Setuptools, but all of the metadata and requirements are included in the `pyproject.toml` file.
It's definitely been a rocky transition, but it's really looking (to me, at least) like we're at (or near) the point where I can just use `pip install …` and it'll work, regardless of the build backend in use!
What are some alternatives?
hasql-interpolate
sigstore-python - A Sigstore client for Python
aws-lambda-python-runtime-interface-client
mais-apis-python - Python client for Stanford MaIS APIs
nixml - NIX + YAML for easy to use reproducible environments
pyenv - Simple Python version management
m1-terraform-provider-helper - CLI to support with downloading and compiling terraform providers for Mac with M1 chip
pip - The Python package installer
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
devenv - Fast, Declarative, Reproducible, and Composable Developer Environments