Is Nix worth the complexity?

[brettdh]

I've been working on several enhancements currently deployed internally at my company, and I have more planned, all of which I'm hoping to submit as pull requests - but I have to say, the Nix-based build process is making it really hard to develop.

Some examples:

• I'm currently trying to add a single package via pip, and running pypi2nix (which is now abandonware) took 24 minutes to run. (In contrast, something like poetry add takes seconds.) Plus, it modified some files in ways that I don't understand, and I don't yet know if it worked.
• To build the docker image on MacOS, I have to run the nix build inside a docker container, because nix busybox package isn't supported on MacOS.
• I'm trying to tweak the docker configuration, and I know my way around a Dockerfile fairly well, but nix adds a new layer of complexity that I have to learn.

It seems like running in Docker is the most common use case. Is running in Nix a use case that still needs to be supported? If not, shedding that complexity would greatly simplify development for potential contributors like me.

My current plan (at some point) is to add a new plain-Dockerfile build process off to the side of the nix build. It's not a super complex app, so there's not a lot to duplicate. Hopefully I can make this a pull request to make this proposal more concrete.

[nejch]

nix looks promising to me in general especially for OS dependencies, but I agree in this context it was easier for me to just test my stuff in a plain python container with pip-installed marge-bot and its deps for #289 (see this quick hack https://gitlab.com/nejch1/test-marge-bot-as-ci-service/-/blob/master/.gitlab-ci.yml#L7-8).

I also think poetry's lockfiles or something similar in combination with any pinned system dependencies in Docker would probably get the job done.

[snim2]

I must admit that whenever I've raised a PR for this project I've just turned TravisCI on for my fork, rather than trying to navigate Nix, but perhaps that's just me!

[qqshfox]

Hi @brettdh @snim2 , thanks for giving the detailed feedbacks. While I was trying Marge on my macOS, I found:

1. nix-shell doesn't even work on macOS. impossible to link (ld / clang) liboping on macOS Big Sur 11 Beta NixOS/nixpkgs#91748 and darwin stdenv can't bootstrap on macOS 11.0 Big Sur NixOS/nixpkgs#104580. Tried update the source to 20.09 but it didn't work either.
2. pypi2nix can't bump requrements.nix. nix-prefetch-github broke pypi2nix nix-community/pypi2nix#464 and similar to Installation fails into fresh virtualenv funkybob/gilbert#17.

I think most pythonistas are more familiar with python's own package management tools and docker related things. So I've submitted a PR #291 to remove nix stuff, and also add a plain-Dockerfile.

[bgamari]

For what it's worth, we use nix in the haskell.org deployment of marge-bot to great effect.

[nejch]

For what it's worth, we use nix in the haskell.org deployment of marge-bot to great effect.

@bgamari I think OP and comments above are mostly about the development workflow since the app itself is quite simple/small so having an idiomatic/familiar build environment that just works on all platforms would probably help first-time contributors. Modern python build tools like poetry would probably bring a level of reproducibility that might have been the original reasoning behind going for nix instead of plain setup.py + Docker.

[snim2]

Yes, it was certainly the developer experience that I was thinking about!

[brettdh]

@bgamari is that because deploying via Nix has some advantage in that context, or that using Docker wouldn't work for some reason? Or is Nix just the approach you happened to go with?

[bgamari]

The reasons are the usual benefits that deploying via Nix offers: reproducible builds allow easy rollback, centralization of configuration makes it easier to build correct systems, and integration with systemd provides good observability. I'm happy to hear that this discussion is limited to development. I just wanted to register that we do use the default.nix provided in the repository in our deployment.

[stolyaroleh]

One reasonable compromise is poetry2nix.
Marge can become a Poetry project, and Nix can parse the lockfile to provide reproducible builds and system dependencies. Contributors can ignore Nix and use Poetry directly.

Regarding busybox not being supported: it's possible to tweak the image expression to include alternatives when building images on macOS.

[brettdh]

@stolyaroleh I'm not following... how can contributors ignore Nix when Nix is how the docker image is built? In order to fully test my contributions, I've been rebuilding and redeploying the Docker container, then creating some dummy MRs and making sure marge-bot does the right thing with whatever change I'm making.

If we could separate the Docker build from the Nix build, then contributors could ignore Nix if they prefer to e2e test in Docker (or vice versa), so long as deps updated via poetry were automatically pulled into both Nix and Docker builds. I think that approach could satisfy developers and deployers in both Nix and Docker workflows, and those who prefer to ignore both.

@qqshfox I think that might be an approach more likely to be accepted. Would you be interested in moving #291 in that direction instead?

[nejch]

@brettdh that sounds more like this project needs proper integration tests that spin up a gitlab (+ gitlab-runner) container and open MRs etc. That's how most API clients and tools that interact with the API (e.g. gitlabform) do it. But you wouldn't need to package the app itself with nix for that IMO, just have it in some poetry/tox venv.

Either way it seems like the community is a lot more active here than maintainers now, so not sure if this will get accepted at some point. Seems like a lot of people are running their own forks based on some of the open PRs because of this. Should we open a separate issue if they need some help to at least clean up old contributions? I don't like running custom forks and currently I'm a bit reluctant to open new PR's because things would cause conflicts with a lot of long-standing open PR's.

[stolyaroleh]

@brettdh, I meant that you will be able to poetry add and poetry run without Nix. Assuming that macOS docker image build is fixed, you could end up with a fast way to both iterate on Marge and build the docker image. If you absolutely want a Dockerfile, I imagine it is possible to poetry build to get a wheel and write few lines that install it in a Python image.

[qqshfox]

@brettdh Pushed a new commit to #291 to introduce poetry.