nix-cde VS globus-timer-cli

This is what I'm using with gitlab: https://github.com/takeda/nix-cde/blob/master/contrib/gitlab...

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.

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)

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.

I use this myself: https://github.com/takeda/nix-cde

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.

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.

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!