marge-bot: Is Nix worth the complexity?

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.

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 4
Comments: 22 (8 by maintainers)

Commits related to this issue

Merge branch 'remove-nix' into 'master' Remove nix Closes #288 See merge request marge-org/marge-bot!291 — committed to alatiera/marge-bot by okias a year ago

Most upvoted comments

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.

nejch on Feb 26, 2021

Hi, we are seriously considering removing nix in marge for the following reasons:

It brings lots of unnecessary complexity to this project
It’s hard for developers, especially new contributors, to test locally and contribute back
It’s broken from time to time (at least on macOS)
Nowadays we have many good tools in python community resolving the same problems.

I opened a PR #291 to remove nix entirely a while ago. And now we plan to include it in the next coming release 0.11.0. Feel free to raise any concern you might have regarding the removal in this thread or in that PR. Thanks.

qqshfox on Jun 3, 2021

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

bgamari on Feb 26, 2021

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

nix-shell doesn’t even work on macOS. https://github.com/NixOS/nixpkgs/issues/91748 and https://github.com/NixOS/nixpkgs/issues/104580. Tried update the source to 20.09 but it didn’t work either.
pypi2nix can’t bump requrements.nix. https://github.com/nix-community/pypi2nix/issues/464 and similar to https://github.com/funkybob/gilbert/issues/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.

qqshfox on Feb 23, 2021