Package request `zulip`

[colemickens]

Package request: https://zulipchat.com/

I'll get to it eventually as I'm going to start using it soon.

(2023 edit: he in fact, did not get to it soon)

[rht]

I don't think it is possible at the moment since the puppet setup for production installation (https://github.com/zulip/zulip/tree/master/puppet) is hardcoded to use apt.

[c0bw3b]

@colemickens the server part or the desktop client? or both?

[colemickens]

@rht I don't know why we'd use puppet at all in nixpkgs. Presumably we would just package the binaries as normal and write a systemd unit.

However, checking that link out makes me realize that Zulip is probably not going to be super straight forward to write a module for. Given that, I'm more likely to focus my attention on getting kubernetes working well on NixOS and then running someone else's manifests/helm chart for running Zulip.

@c0bw3b both, but I was more focused on the server since I've only used the web client. But, given my response to @rht, I'm going to close this out as I no longer desire it or have any intention of working on it. Of course, it can be re-opened if someone else still wants it.

[rht]

I am in the process of yanking away the apt dependencies in https://github.com/zulip/zulip/pull/10968. But I figure that puppet's package doesn't have nix as a provider anyway, so, the only sensible path is to rewrite the entire puppet part into nix. I saw that tsearch-extras and PGroonga have already existed in nixpkgs, so it is halfway-done.

[Ma27]

@rht first of all, do you intend to continue working on this? I'm not sure if I want to spend time one this (yet), but if so it would be better if we join forces, it would be a shame if we have two different PRs in the end as packaging this is rather complex.

As I know some people who were also interested in having this packaged, I also had a look at this. First of all I guess I'm against using their installer. I don't understand it entirely yet, but patching this accordingly to get it working on NixOS would be far too much effort. I'd propose an approach similar to the one taken for GitLab where we created our own module with all functionality implemented here rather than patching one of upstream's installation approaches.

[rht]

@Ma27 yeah sure! Since then I have tested the malleability of the setup process by making it run on CentOS/RHEL/Fedora. Dev environment: https://github.com/zulip/zulip/pull/11004 (finished, but most of the commits are rebased into upstream instead of merged), production environment: https://github.com/zulip/zulip/pull/11091 (wip).

The production setup has a lot of assumption with the path of postgresql config. I was told to start from porting dev env first as a checkpoint, then prod env. The dev setup has less assumption about the FHS structure, but still store pip/npm/node/emoji caches in /srv/. You can make the skeleton (via buildFHSUserEnv for now?) and I can fill in the details since at this point I have touched all the relevant files. For dev env, IIRC, most of it consists of installing the relevant packages and making sure the services are enabled.

[rht]

Relevant commits: https://github.com/zulip/zulip/commits/master?after=c6371bb3ef1b3bc310cc457944289fe414e81eb6+454, https://github.com/zulip/zulip/commits/master?after=c6371bb3ef1b3bc310cc457944289fe414e81eb6+419, https://github.com/zulip/zulip/commits/master?before=c6371bb3ef1b3bc310cc457944289fe414e81eb6+420 (all the commits with the prefix provision:).

[yugawara]

What's the latest status? I would like to try Zulip on NixOS!

[rht]

There was a recent discussion at chat.zulip.org to replace all of Zulip installation mechanism (including Puppet) into Nix so that it runs everywhere: https://chat.zulip.org/#narrow/stream/3-backend/topic/thumbor/near/835261.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[ZoomRmc]

Still important to me.

[kira-bruneau]

Should this be closed now? Zulip isn't packaged from source, but it's packaged from an AppImage: https://github.com/NixOS/nixpkgs/pull/73094

[andersk]

73094 was Zulip Desktop (the client app). This issue is for Zulip Server.

[maddiemort]

This is still important to me too. Has there been any recent activity surrounding this?

[rht]

You can check out https://discourse.nixos.org/t/mach-nix-pip2nix-poetry2nix-or-pynixify-for-zulip-provision/18836.

[RaitoBezarius]

I am very interested into giving some help to get Zulip progressively into NixOS, can I do something @rht ?

[rht]

I think there is this blocking issue: https://github.com/nix-community/poetry2nix/issues/627.

[RaitoBezarius]

I think there is this blocking issue: nix-community/poetry2nix#627.

I commented there as I do not think this is still an issue, according to the latest version of poetry2nix.

[RaitoBezarius]

@rht I tried to package the Node.js frontend and was met with

❯ yarn2nix       Error: Command failed: nix-prefetch-git --rev 92c4dd33b9add115ec436ef25243484cca0f7355#7d0a319a9d6df18736913f34e4a6ec01f68b0486 https://github.com/andersk/postcss-media-minmax.git --fetch-submodules
    at checkExecSyncError (node:child_process:871:11)
    at execFileSync (node:child_process:907:15)
    at prefetchgit (/nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/deps/yarn2nix/lib/generateNix.js:36:5)
    at fetchgit (/nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/deps/yarn2nix/lib/generateNix.js:60:23)
    at /nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/deps/yarn2nix/lib/generateNix.js:93:14
    at _map (/nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/node_modules/ramda/src/internal/_map.js:6:19)
    at map (/nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/node_modules/ramda/src/map.js:64:14)
    at /nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/node_modules/ramda/src/internal/_dispatchable.js:41:15
    at Object.f2 [as map] (/nix/store/rk1hz9pazyrzpm1k9rx264v7zkr2jq7s-yarn2nix-1.0.0/libexec/yarn2nix/node_modules/ramda/src/internal/_curry2.js:29:14) {
  status: 1,
  signal: null,
  output: [ null, <Buffer >, null ],
  pid: 2798505,
  stdout: <Buffer >,
  stderr: null
}

It seems like that

❯ nix-prefetch-git --rev "92c4dd33b9add115ec436ef25243484cca0f7355#7d0a319a9d6df18736913f34e4a6ec01f68b0486" https://github.com/andersk/postcss-media-minmax.git --fetch-submodules
Dépôt Git vide initialisé dans /run/user/1000/git-checkout-tmp-NwP4WVFW/postcss-media-minmax/.git/
fatal : impossible de trouver la référence distante refs/tags/92c4dd33b9add115ec436ef25243484cca0f7355#7d0a319a9d6df18736913f34e4a6ec01f68b0486
remote: Enumerating objects: 43, done.
remote: Counting objects: 100% (43/43), done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 43 (delta 7), reused 12 (delta 1), pack-reused 0
Dépaquetage des objets: 100% (43/43), 25.04 Kio | 2.50 Mio/s, fait.
Depuis https://github.com/andersk/postcss-media-minmax
 * branch            HEAD       -> FETCH_HEAD
fatal : Not a valid object name 
Unrecognized git object type: 
Unable to checkout refs/tags/92c4dd33b9add115ec436ef25243484cca0f7355#7d0a319a9d6df18736913f34e4a6ec01f68b0486 from https://github.com/andersk/postcss-media-minmax.git.

the object do not exist anymore, I suppose the split is wrong, it should be only the first before # or after.

The package/lockfile reference is some sort of codeload.github.com path, is it normal?

[rht]

The package/lockfile reference is some sort of codeload.github.com path, is it normal?

Hmmm, @andersk can explain better. This is the relevant commit, and this commit has the rationale.

[RaitoBezarius]

The package/lockfile reference is some sort of codeload.github.com path, is it normal?

Hmmm, @andersk can explain better. This is the relevant commit, and this commit has the rationale.

Hm I get it, but I think it made have sense at a moment, but I wonder if this is still needed. I imagine it would require patching yarn2nix-moretea to support this kind of URLs.

[rht]

On the Python end, I tried poetry2nix again, since https://github.com/nix-community/poetry2nix/issues/627 has been closed. Had to do https://github.com/python-poetry/poetry/issues/1917#issuecomment-1251667047 to generate the lock file. Encountered this problem because I set preferWheels = true. I don't know how to apply the work arround in https://github.com/nix-community/poetry2nix/issues/784#issuecomment-1308586385.

[RaitoBezarius]

On the Python end, I tried poetry2nix again, since nix-community/poetry2nix#627 has been closed. Had to do python-poetry/poetry#1917 (comment) to generate the lock file. Encountered this problem because I set preferWheels = true. I don't know how to apply the work arround in nix-community/poetry2nix#784 (comment).

I tried again and met my end at https://github.com/nix-community/poetry2nix/issues/878 ; I know how to apply the workaround but cannot reach your steps.

I am working on converting the Zulip project to vanilla NPM to reuse buildNpmPackage, having some difficulties with native addons packages requiring Python 3 at the moment, but I think I am a lot closer.

If the Zulip frontend is using this function, it can be included in upstream IMHO (otherwise lockfile would be too much.) For Zulip backend, I suppose we can do a similar thing.

Okay, great: can run ./tools/webpack (failing due to missing generated contents related to Python).

Now, only left to package Python stuff so I can intertwine everything. :)

See https://github.com/RaitoBezarius/zulip/commit/b158254e790b4979c9fc12f06fec76f237a2d0d6 for my current work, cc @andersk

[andersk]

I tried again and met my end at https://github.com/nix-community/poetry2nix/issues/878

We won’t need pip and pip-tools in a world where we’ve migrated to Poetry, so those can be left out. But I expect there are still other poetry2nix issues still to be addressed: the subdirectory field added in Poetry 1.2 will need to be supported in poetry2nix.

I am working on converting the Zulip project to vanilla NPM to reuse buildNpmPackage,

That might be okay but needs some thought. Shouldn’t yarn2nix work with our existing Yarn packages?

Either way, we’ll want to keep the upstream package manager’s lock file (yarn.lock or package-lock.json) so we can inspect and update it with standard tools (yarn or npm CLI, Dependabot).

[RaitoBezarius]

I tried again and met my end at nix-community/poetry2nix#878

We won’t need pip and pip-tools in a world where we’ve migrated to Poetry, so those can be left out. But I expect there are still other poetry2nix issues still to be addressed: the subdirectory field added in Poetry 1.2 will need to be supported in poetry2nix.

Unfortunately, zulip_bots has a dependency on pip. :'( But, someone found the root cause of the issue, so I may get started again on that.

I think the subdirectory field is more or less working, but I would need to check.

I am working on converting the Zulip project to vanilla NPM to reuse buildNpmPackage,

That might be okay but needs some thought. Shouldn’t yarn2nix work with our existing Yarn packages?

Alas, yarn2nix is semi-broken, given it's stuck at Yarn v1 and cannot handle a lot of stuff, I met https://github.com/NixOS/nixpkgs/issues/174114 and frankly, I have no idea what is going on.

Either way, we’ll want to keep the upstream package manager’s lock file (yarn.lock or package-lock.json) so we can inspect and update it with standard tools (yarn or npm CLI, Dependabot).

Yes, but we won't need to commit it upstream (in nixpkgs) to package it, whereas yarn2nix force to commit the yarn.nix. It will be easier to accept upstream through buildNpmPackage IMHO.

[RaitoBezarius]

Got in shape poetry2nix mostly for everything, now I met my end on this dependency https://github.com/kichik/tlds/blob/master/setup.py that Zulip uses. Which require non-trivial patching for offline installs.

[andersk]

Unfortunately, zulip_bots has a dependency on pip. :'(

It doesn’t actually use Pip unless the user invokes the silly --provision mechanism to auto-install dependencies; that’s obviously not going to work on Nix so we can skip it. (I’ll see if we can rip it out upstream.)

Alas, yarn2nix is semi-broken, given it's stuck at Yarn v1

Yarn v1 is what we’re on. Later versions are effectively a different project, so it’s not surprising they’d need different Nix tooling.

Admittedly, we probably won’t want to stay on Yarn v1 forever, and pnpm2nix looks bit-rotted, so maybe NPM is the logical long-term choice.

whereas yarn2nix force to commit the yarn.nix.

FWIW, this is a Hydra restriction (no IFD), not a yarn2nix requirement—I guess it hasn’t been spelled out here, but speaking for Zulip upstream, we are interested in migrating to Nix there, in which case we won’t be bound by Hydra restrictions.

I met #174114 and frankly, I have no idea what is going on.

I haven’t investigated, but I wonder if js2nix works better?

now I met my end on this dependency https://github.com/kichik/tlds/blob/master/setup.py

That’s wacky, but the PyPI wheel should work, right?

[RaitoBezarius]

Unfortunately, zulip_bots has a dependency on pip. :'(

It doesn’t actually use Pip unless the user invokes the silly --provision mechanism to auto-install dependencies; that’s obviously not going to work on Nix so we can skip it. (I’ll see if we can rip it out upstream.)

Makes sense, for now, I would need to edit the zulip_bots requirements to remove it, so I will just make it work with.

Alas, yarn2nix is semi-broken, given it's stuck at Yarn v1

Yarn v1 is what we’re on. Later versions are effectively a different project, so it’s not surprising they’d need different Nix tooling.

Admittedly, we probably won’t want to stay on Yarn v1 forever, and pnpm2nix looks bit-rotted, so maybe NPM is the logical long-term choice.

I think, ironically, this is the most supported one, at the moment. Plus, npmlock2nix has been improved for V2 lockfiles from what I have seen, so plenty of good options for NPM packages.

whereas yarn2nix force to commit the yarn.nix.

FWIW, this is a Hydra restriction (no IFD), not a yarn2nix requirement—I guess it hasn’t been spelled out here, but speaking for Zulip upstream, we are interested in migrating to Nix there, in which case we won’t be bound by Hydra restrictions.

Right, on my part, I am interested into upstreaming Zulip packaging into NixOS for self-hosting, so I am bound by Hydra restrictions :P.

More generally, this is not only a Hydra restriction, committing a very large yarn.nix is annoying for everyone increasing drastically the size of the repository, so having a nice solution for this is appreciated.

I met #174114 and frankly, I have no idea what is going on.

I haven’t investigated, but I wonder if js2nix works better?

Did not try, but, as buildNpmPackage is quite efficient to this, I will not try and focus on assembling everything to have a self hosted prototype.

now I met my end on this dependency https://github.com/kichik/tlds/blob/master/setup.py

That’s wacky, but the PyPI wheel should work, right?

Tried multiple things but uncertain, I have a lot of changes to send back upstream on poetry2nix related to the changes being used.

For example, py3dns have fun by reading /etc/resolv.conf at install-time… :') — so I added a patch to disable nameservers discovery at install-time.

[andersk]

Right, on my part, I am interested into upstreaming Zulip packaging into NixOS for self-hosting, so I am bound by Hydra restrictions :P.

The intention would be to move even self-hosted installations to Nix—is a first-party flake or overlay something you’d be interested in?

(There’s a bit of related discussion in our development community. Feel free to join us there with any questions or ideas!)

[RaitoBezarius]

Right, on my part, I am interested into upstreaming Zulip packaging into NixOS for self-hosting, so I am bound by Hydra restrictions :P.

The intention would be to move even self-hosted installations to Nix—is a first-party flake or overlay something you’d be interested in?

A first-party Flake or overlay would be great, but, I am interested into maintaining a NixOS module in-tree to offer Zulip in stable releases of NixOS.

Of course, it may lag behind official releases, but I am fine with this.

[RaitoBezarius]

Now at https://github.com/jaysonsantos/python-binary-memcached/issues/249 :).

[RaitoBezarius]

Reached the end and stuck on some Poetry build-system stuff for Zulip:

❯ nix-build default.nix -A env
these 2 derivations will be built:
  /nix/store/i61bc4yg5s219rkglm1q6w9jvv9882zp-python3.10-zulip-backend-6.0.0.drv
  /nix/store/3s7bv4345h93vvvwp1g41kzhrm8fihm1-python3-3.10.8-env.drv
building '/nix/store/i61bc4yg5s219rkglm1q6w9jvv9882zp-python3.10-zulip-backend-6.0.0.drv' on 'ssh://nix-community-build01'...
copying 1 paths...
copying path '/nix/store/j5awn6y3yhmamik9bqwbz0qdr7768aak-source' to 'ssh://nix-community-build01'...
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing pip-build-hook
Using pipBuildPhase
Using pipShellHook
Sourcing pip-install-hook
Using pipInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
unpacking sources
unpacking source archive /nix/store/j5awn6y3yhmamik9bqwbz0qdr7768aak-source
source root is source
setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/zproject/wsgi.py
patching sources
Removing path dependencies
Finished removing path dependencies
Removing git dependencies
Finished removing git dependencies
configuring
no configure script, doing nothing
building
Executing pipBuildPhase
Creating a wheel...
WARNING: The directory '/homeless-shelter/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.
Processing /build/source
  Running command Preparing metadata (pyproject.toml)
  Traceback (most recent call last):
    File "/nix/store/9jr955f5rhr00rvql5gq0c99sw8378km-python3.10-pip-22.2.2/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
      main()
    File "/nix/store/9jr955f5rhr00rvql5gq0c99sw8378km-python3.10-pip-22.2.2/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/nix/store/9jr955f5rhr00rvql5gq0c99sw8378km-python3.10-pip-22.2.2/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 164, in prepare_metadata_for_build_wheel
      return hook(metadata_directory, config_settings)
    File "/nix/store/455k9z0sl0571q286276a1xr9kh8r9wk-python3.10-poetry-1.2.2/lib/python3.10/site-packages/poetry/core/masonry/api.py", line 40, in prepare_metadata_for_build_wheel
      poetry = Factory().create_poetry(Path(".").resolve(), with_groups=False)
    File "/nix/store/455k9z0sl0571q286276a1xr9kh8r9wk-python3.10-poetry-1.2.2/lib/python3.10/site-packages/poetry/core/factory.py", line 58, in create_poetry
      raise RuntimeError("The Poetry configuration is invalid:\n" + message)
  RuntimeError: The Poetry configuration is invalid:
    - [dependencies.talon-core] {'subdirectory': 'talon-core', 'version': '*'} is not valid under any of the given schemas
    - [dependencies.zulip] {'subdirectory': 'zulip', 'version': '*'} is not valid under any of the given schemas
    - [dependencies.zulip-bots] {'subdirectory': 'zulip_bots', 'version': '*'} is not valid under any of the given schemas
    - [packages.0] 'zulip' is not of type 'object'
    - [packages.1] 'zulip_bots' is not of type 'object'
    - [packages.2] 'zulip_botserver' is not of type 'object'

  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /nix/store/nzgqxw4d875pgl1lji8n3q82x3bf7ldi-python3-3.10.8/bin/python3.10 /nix/store/9jr955f5rhr00rvql5gq0c99sw8378km-python3.10-pip-22.2.2/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /build/tmph1rxgn65
  cwd: /build/source
  Preparing metadata (pyproject.toml) ... error
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

I don't know how well it is supposed to be supported by Poetry ≥ 1.2.0.

[andersk]

A first-party Flake or overlay would be great, but, I am interested into maintaining a NixOS module in-tree to offer Zulip in stable releases of NixOS.

Alright, that’s great too. I’m sure we can share significant work!

Now at https://github.com/jaysonsantos/python-binary-memcached/issues/249 :).

The problem is slightly misdiagnosed there. m2r, though unmaintained, is still installable. Meanwhile, the python-binary-memcached PyPI tarball is missing the CHANGELOG.md that its setup.py needs to read. (Opened jaysonsantos/python-binary-memcached#251.)

Reached the end and stuck on some Poetry build-system stuff for Zulip:

Yeah, now you’ll start reaching the subdirectory problem I mentioned above. Though the 'version': '*' suggests you’re trying to pull these modules from PyPI? You will need to pull them from Git.

[RaitoBezarius]

A first-party Flake or overlay would be great, but, I am interested into maintaining a NixOS module in-tree to offer Zulip in stable releases of NixOS.

Alright, that’s great too. I’m sure we can share significant work!

Definitely :)

Now at jaysonsantos/python-binary-memcached#249 :).

The problem is slightly misdiagnosed there. m2r, though unmaintained, is still installable. Meanwhile, the python-binary-memcached PyPI tarball is missing the CHANGELOG.md that its setup.py needs to read.

Indeed, so I just patched all the stuff. m2r is broken in nixpkgs in NixOS.

Reached the end and stuck on some Poetry build-system stuff for Zulip:

Yeah, now you’ll start reaching the subdirectory problem I mentioned above. Though the 'version': '*' suggests you’re trying to pull these modules from PyPI? You will need to pull them from Git.

So poetry2nix do not understand those when generating the poetry-git-overlay, but I can still "understand" subdirectories by using sourceRoot properly, see https://github.com/RaitoBezarius/zulip/blob/main/poetry-git-overlay.nix

Though, poetry is not understanding those.

(I am using also a private fork for poetry2nix as I had to do some changes which I will upstream soon).

[andersk]

This was working for me with upstream Poetry when I last looked at it. It’s a bit outdated, but does poetry install successfully:

https://gist.github.com/andersk/94423a8ccb57afe66bb731b487d29102

[RaitoBezarius]

This was working for me with upstream Poetry when I last looked at it. It’s a bit outdated, but does poetry install successfully:

https://gist.github.com/andersk/94423a8ccb57afe66bb731b487d29102

I don't think poetry install produces a package of the "current Python application" and install this package.

I am stuck at the step at turning the whole Zulip project into a Python package which I can deploy without keeping the whole Git source tree.

[andersk]

Oh, well, you’re not going to have a fun time with that. 😛

We don’t really have a package that can be installed in the normal way; we have a bunch of code that expects to run within the source tree in a particular Python environment.

[RaitoBezarius]

Oh, well, you’re not going to have a fun time with that. stuck_out_tongue

We don’t really have a package that can be installed in the normal way; we have a bunch of code that expects to run within the source tree in a particular Python environment.

Ha, in that case, maybe I should stop there and have the environment then run uWSGI/etc.

Do you know if there is any plan to support running the WSGI server while only having the backend package installed?

I know that for frontend, there's lots of stuff to generate, before running Webpack, but I do not have yet a clear big picture of all the moving parts.

[andersk]

It’s a reasonable wishlist item, but unlikely to be a priority any time soon. Even if you were to tear out the frontend, the backend depends on generated files too (e.g. static/webpack-bundles/katex-cli.js, static/generated/{bots,emoji/*.json,pygments_data.json,timezones.json, templates/zerver/emails/compiled). The closest thing to an overview of all there is to set up might be the scripts/lib/upgrade-zulip-stage-2 and tools/update-prod-static scripts.

[luochen1990]

Is there any progress?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/pre-rfc-call-for-discussion-opening-a-new-chat-collaboration-platform/34693/1

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-community-zulip/11683/10