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.

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!

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.

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

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.

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

@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?

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.

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.

@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?

@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.

@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.

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

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.

This is what I am doing in https://github.com/niteoweb/pyramid-realworld-example-app/ with success. I am happy because Nix prepares my dev environment, but other contributors are not forced to use Nix -- they can use their system-installed Python & Poetry.

nix-shell doesn't even work on macOS. NixOS/nixpkgs#91748 and NixOS/nixpkgs#104580. Tried update the source to 20.09 but it didn't work either.

The fact that the latest stable branch of nixpkgs does not support Big Sur is very unfortunate and my hope is that projects such as https://opencollective.com/nix-macos will prevent such cases in the future. In the meantime, if you upgrade the source to nixpkgs-unstable it should work.

Interesting... so instead of using nix natively on the dev/CI platform to build docker images, you use it inside a Dockerfile to run a normal Nix app inside a container. This makes a ton of sense to me from the standpoint of being able to ignore nix if desired.

My remaining questions

1. Do devs have to do anything nix-related when adding or removing python deps with poetry. (I haven't dug far enough into the details to be sure.) If not, your solution sounds ideal.
2. You mentioned that Nix prepares your dev environment; is the app also deplorable with Nix?

I'll read a bit more to understand better, but that's where I'm at after a quick glance.

Do devs have to do anything nix-related when adding or removing python deps with poetry. (I haven't dug far enough into the details to be sure.) If not, your solution sounds ideal.

No, devs can ignore Nix. Nix in https://github.com/niteoweb/pyramid-realworld-example-app/ is configured to read poetry.lock and install whatever is in there. One can use system-installed poetry to update poetry.lock and all people using Nix would get updated enviroments too.

You mentioned that Nix prepares your dev environment; is the app also deplorable with Nix?

It is! The app is deployed to Heroku, via https://github.com/niteoweb/pyramid-realworld-example-app/blob/master/Dockerfile which basically runs nix-shell to build everything that is needed in production. But one can definitely deploy the app using more mainstream Python deployment tooling, via poetry, or similar.

https://blog.niteo.co/project-isolation-beyond-requirements-txt/ is a good intro into to why Nix makes so much sense.

Lol, whoops - deployable, not deplorable 😬😅

I see that you run the app in Nix in the Dockerfile; I was wondering if it can be deployed using Nix without Docker involved, as it sounds like @bgamari does in the haskell.org context. At a glance, it seems like yes, but I'm not familiar enough with Nix to be sure.

Yep, people do that. It's my personal taste to really like Heroku, and on Heroku, deploying via Dockerfile makes the most sense.

You linked the issue that I opened about nix on macOS and finally, I abandoned nix.

It's a nightmare to have it working as expected, you update macOS, and nix is broken, something that I can't imagine for a professional workstation.
I left also about the disk space that it uses.
My containers are all built using buildah, I left Dockerfile too to be directly using a pure shell to do it (no more magic).

I liked nix but waiting a lot of time to be able to update my laptop, sorry it's not compatible.

Another reason to leave nix was about migrating existing automation (Ansible and SaltStack) to nixOS.
In addition, it's also about the availability of nixOS on different cloud providers to avoid the need to create our image.

I'll retry nix when it'll be more professional (with full SELinux support including all standard policies like RHEL) and less brain burner.

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

1. It brings lots of unnecessary complexity to this project
2. It's hard for developers, especially new contributors, to test locally and contribute back
3. It's broken from time to time (at least on macOS)
4. 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.

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

I fully support your decision.

I would like to clarify some issues that I think are due to a lack of communication from the Nix community rather than issues with Nix itself.

1. It brings lots of unnecessary complexity to this project

If your goal is to set up a developer environment, then it's debatable if complexity is the culprit rather than familiarity?

We now have tutorials for developer environments to onboard people into how it all works.

Docker brings the overhead of running and operating a container, which I'd say is more complex, but that's hard to judge since complexity is hard to measure.

2. It's hard for developers, especially new contributors, to test locally and contribute back

Would it help to write how to do common tasks? Like bumping a package, developing locally?

3. It's broken from time to time (at least on macOS)

That's fixed. macOS funding campaign such issues should be resolved much quickly.

4. Nowadays we have many good tools in python community resolving the same problems.

poetry2nix is the what Nix community prefers these days that works well with Poetry.

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.

👍