[OTHER] New build system not compatible with Nix in many places #59

Closed
opened 2026-02-19 13:22:09 +01:00 by ddogfoodd · 24 comments
Contributor

Please explain your inquiry.

I am opening this issue to start a discussion. I might miss something here or someone more experienced might have an idea.
(Opening in the Dove repo, as this is where I encountered the problem. Should apply to Phoenix as well but Dove build fails first for me. Let me know if I should open an issue for Phoenix and link here.)

I have tried to adjust the build scripts of Dove and Phoenix to work with Nix but failed to do so until now.
Unless I am missing something, I think there is no simple solution to get Dove and Phoenix to build on Nix with the new build system. As I see it, it just isn't vey compatible with the limitations of Nix.

Nix generally doesn't allow to write files or create dirs in the nix-store during build. Instead it can use a tmp dir during buildPhase, then build, then copy outputs during installPhase (someone had a similar problem here).

This leads to build failures in a lot of places when trying to build Phoenix or Dove. Mostly this happens whenever files / dirs are written / created under DOVE_BUILD.
Some are easy to fix, e.g. setting DOVE_LOG_BUILD=0 and PHOENIX_LOG_BUILD=0 in flake.nix or nix/package.nix. However, there some more occurences that might require more branching in the build scripts, e.g. by checking for the value of our recently introduced DOVE_NIX_FLAKE env variable and writing files to a /tmp dir. Then we have to also adjust the parts that consume such files to use the /tmp dir. I think this would quite some modifications in the build scripts and therefore break very easily.

I thought, maybe we can just copy the whole build dir to /tmp and just set DOVE_BUILD to that copy, this should allow us to write files and create dirs and I think we can then just adjust the nix installPhase to copy the results from there. However, I am not sure yet if setting DOVE_BUILD would break other parts of the build script.

I will continue to try to fix it but wanted to get this out there, in case anyone has a better idea.

### Please explain your inquiry. I am opening this issue to start a discussion. I might miss something here or someone more experienced might have an idea. (Opening in the Dove repo, as this is where I encountered the problem. Should apply to Phoenix as well but Dove build fails first for me. Let me know if I should open an issue for Phoenix and link here.) I have tried to adjust the build scripts of Dove and Phoenix to work with Nix but failed to do so until now. Unless I am missing something, I think there is no simple solution to get Dove and Phoenix to build on Nix with the new build system. As I see it, it just isn't vey compatible with the limitations of Nix. Nix generally doesn't allow to write files or create dirs in the nix-store during build. Instead it can use a tmp dir during buildPhase, then build, then copy outputs during installPhase (someone had a similar problem [here](https://discourse.nixos.org/t/permission-denied-during-installphase-of-a-python-program/35992)). This leads to build failures in a lot of places when trying to build Phoenix or Dove. Mostly this happens whenever files / dirs are written / created under `DOVE_BUILD`. Some are easy to fix, e.g. setting `DOVE_LOG_BUILD=0` and `PHOENIX_LOG_BUILD=0` in `flake.nix` or `nix/package.nix`. However, there some more occurences that might require more branching in the build scripts, e.g. by checking for the value of our recently introduced `DOVE_NIX_FLAKE` env variable and writing files to a `/tmp` dir. Then we have to also adjust the parts that consume such files to use the `/tmp` dir. I think this would quite some modifications in the build scripts and therefore break very easily. I thought, maybe we can just copy the whole build dir to `/tmp` and just set `DOVE_BUILD` to that copy, this should allow us to write files and create dirs and I think we can then just adjust the nix installPhase to copy the results from there. However, I am not sure yet if setting `DOVE_BUILD` would break other parts of the build script. I will continue to try to fix it but wanted to get this out there, in case anyone has a better idea.
Owner

Thanks for the report, let's definitely get this taken care of.

This leads to build failures in a lot of places when trying to build Phoenix or Dove. Mostly this happens whenever files / dirs are written / created under DOVE_BUILD.
Some are easy to fix, e.g. setting DOVE_LOG_BUILD=0 and PHOENIX_LOG_BUILD=0 in flake.nix or nix/package.nix. However, there some more occurences that might require more branching in the build scripts, e.g. by checking for the value of our recently introduced DOVE_NIX_FLAKE env variable and writing files to a /tmp dir. Then we have to also adjust the parts that consume such files to use the /tmp dir. I think this would quite some modifications in the build scripts and therefore break very easily.

DOVE_BUILD (and PHOENIX_BUILD) currently aren't configurable, so I don't think just changing them would work. I think the first thing we need to do to fix this is make both of those envs configurable. I don't think it being configurable should cause any issues. I think we should also add a check for Nix at env_helpers (We can probably just move the existing logic for ex. DOVE_NIX_FLAKE from env_common, and implement that in Phoenix as well). Once we do that, we can make it so that the default paths for DOVE_BUILD (and PHOENIX_BUILD) for Nix are /tmp (instead of the standard/current location). We can also do the same for the log location, and any other vars as necessary.

I'll work on this later today/tomorrow. Making this a priority to fix, apologies for the issues here.

Thanks for the report, let's definitely get this taken care of. > This leads to build failures in a lot of places when trying to build Phoenix or Dove. Mostly this happens whenever files / dirs are written / created under DOVE_BUILD. > Some are easy to fix, e.g. setting DOVE_LOG_BUILD=0 and PHOENIX_LOG_BUILD=0 in flake.nix or nix/package.nix. However, there some more occurences that might require more branching in the build scripts, e.g. by checking for the value of our recently introduced DOVE_NIX_FLAKE env variable and writing files to a /tmp dir. Then we have to also adjust the parts that consume such files to use the /tmp dir. I think this would quite some modifications in the build scripts and therefore break very easily. `DOVE_BUILD` *(and `PHOENIX_BUILD`)* currently aren't configurable, so I don't think just changing them would work. I think the first thing we need to do to fix this is make both of those envs configurable. I don't *think* it being configurable should cause any issues. I think we should also add a check for Nix at `env_helpers` *(We can probably just move the existing logic for ex. `DOVE_NIX_FLAKE` from `env_common`, and implement that in Phoenix as well)*. Once we do that, we can make it so that the default paths for `DOVE_BUILD` *(and `PHOENIX_BUILD`)* for Nix are `/tmp` *(instead of the standard/current location)*. We can also do the same for the log location, and any other vars as necessary. I'll work on this later today/tomorrow. Making this a priority to fix, apologies for the issues here.
Owner

I think we should also add a check for Nix at env_helpers (We can probably just move the existing logic for ex. DOVE_NIX_FLAKE from env_common, and implement that in Phoenix as well).

NVM, I forgot to account for the fact that Nix can be used on both Linux and OS X. So it'll be best to keep using a separate dedicated env variable here.

> I think we should also add a check for Nix at `env_helpers` (We can probably just move the existing logic for ex. `DOVE_NIX_FLAKE` from `env_common`, and implement that in Phoenix as well). NVM, I forgot to account for the fact that Nix can be used on both Linux and OS X. So it'll be best to keep using a separate dedicated env variable here.
Owner

Hey @ddogfoodd, Do you mind trying to install Phoenix from its dev branch, and confirm that the install works? I made some changes that I believe should help fix this issue. If Phoenix installs as expected, I'll implement changes of the same nature for Dove as well - but first want to confirm that it does work correctly.

Hey @ddogfoodd, Do you mind trying to install Phoenix from its `dev` branch, and confirm that the install works? I made some changes that I believe should help fix this issue. If Phoenix installs as expected, I'll implement changes of the same nature for Dove as well - but first want to confirm that it does work correctly.
Author
Contributor

@celenity Phoenix dev branch builds fine. Thank you very much!

@celenity Phoenix `dev` branch builds fine. Thank you very much!
Owner

Great, thanks for confirming! Will implement the same changes for Dove.

Great, thanks for confirming! Will implement the same changes for Dove.
Owner

Should now be fixed (for the dev branch currently, though I do intend to have a release out within the next few days, so will be fixed on production/pages then)! Please LMK if you have any further issues.

Should now be fixed *(for the `dev` branch currently, though I do intend to have a release out within the next few days, so will be fixed on production/`pages` then)*! Please LMK if you have any further issues.
Author
Contributor

The build was still broken for me, but I wanted to wait for the new dove release, just to be sure.
#61 seems to fix the build.

The build was still broken for me, but I wanted to wait for the new dove release, just to be sure. #61 seems to fix the build.
Owner

Hey @ddogfoodd, if you have a chance and don't mind, can you please test installing Dove on Nix from the dev branch? I made some changes to how Python is handled that I suspect might cause issues with Nix, so I'd like to test and resolve them before next release.

The main change I made was adding a few new environment variables:

  • DOVE_PIP_EXEC - Location of pip
  • DOVE_PYTHON - Location of python

I did also have to set an instance in the build script to call Python from ${DOVE_PIP_DIR}/bin/python - for some reason, using DOVE_PYTHON didn't seem to work there.

My guess is we'll need to configure these variables for Nix, but I'm not sure how we should configure them and what we should set the values to. Please LMK if you have any thoughts.

also cc: @jbgi Curious if you have any thoughts.

Hey @ddogfoodd, if you have a chance and don't mind, can you please test installing Dove on Nix from the `dev` branch? I made some changes to how Python is handled that I suspect might cause issues with Nix, so I'd like to test and resolve them before next release. The main change I made was adding a few new environment variables: - `DOVE_PIP_EXEC` - Location of `pip` - `DOVE_PYTHON` - Location of `python` I did also have to set an instance in the build script to call Python from `${DOVE_PIP_DIR}/bin/python` - for some reason, using `DOVE_PYTHON` didn't seem to work there. My guess is we'll need to configure these variables for Nix, but I'm not sure how we should configure them and what we should set the values to. Please LMK if you have any thoughts. also cc: @jbgi Curious if you have any thoughts.
Author
Contributor

Fails with /build/4y8mxs0y70lwlhpasm3a727mc228z4v2-source/scripts/build-dove.sh: line 80: /tmp/dove/build/pyenv/bin/python: No such file or directory

AFAIK for nix we probably want to skip pip and instead add requirements to the nativeBuildInputs (here in the flake). nativeBuildInputs is for things required during build time rather than run time, which probably always applies since we just build the dove config.
So I think we just skip pip in the build scripts and the DOVE_PIP_EXEC env var when DOVE_NIX is set.

I think we can skip DOVE_PYTHON as well and just use python without specifying the path to the python binary when using nix. I can take a look later. I think we could also set DOVE_PYTHON to the python path in the nix-store. I don't see a point in doing so, if skipping it works, though.

Fails with `/build/4y8mxs0y70lwlhpasm3a727mc228z4v2-source/scripts/build-dove.sh: line 80: /tmp/dove/build/pyenv/bin/python: No such file or directory` AFAIK for nix we probably want to skip pip and instead add requirements to the `nativeBuildInputs` ([here in the flake](https://codeberg.org/celenity/Dove/src/commit/61190ba00713e200c2688110172e2528e47d61cd/flake.nix#L108)). `nativeBuildInputs` is for things required during build time rather than run time, which probably always applies since we just build the dove config. So I think we just skip pip in the build scripts and the `DOVE_PIP_EXEC` env var when `DOVE_NIX` is set. I think we can skip `DOVE_PYTHON` as well and just use `python` without specifying the path to the python binary when using nix. I can take a look later. I think we could also set `DOVE_PYTHON` to the python path in the nix-store. I don't see a point in doing so, if skipping it works, though.
Author
Contributor

I think the easiest way of handling this would be #65.

Otherwise we could set DOVE_PYTHON or DOVE_PIP_DIR like this. However, this would result in a "ModuleNotFoundError: No module named 'lxml'" error, even when using DOVE_PIP_DIR.
I am not sure how to fix this the nix way at the moment. Just wanted to throw it in here, in case you prefer setting the env var even when using nix and someone else knows how we can get the dependencies in there as well.

Thank you for caring about us nix users btw. I am thankful for your work and always happy to test and help where I can.

I think the easiest way of handling this would be #65. Otherwise we could set `DOVE_PYTHON` or `DOVE_PIP_DIR` [like this](https://codeberg.org/ddogfoodd/Dove/src/commit/0db06024c22ff8b7a7dbd0983d4e1b8efba258aa/flake.nix#L121). However, this would result in a "ModuleNotFoundError: No module named 'lxml'" error, even when using `DOVE_PIP_DIR`. I am not sure how to fix this the nix way at the moment. Just wanted to throw it in here, in case you prefer setting the env var even when using nix and someone else knows how we can get the dependencies in there as well. Thank you for caring about us nix users btw. I am thankful for your work and always happy to test and help where I can.
Owner

Thank you! I just merged your PR - that sounds like a reasonable solution for the time being. Appreciate your time and assistance.

Thank you! I just merged your PR - that sounds like a reasonable solution for the time being. Appreciate your time and assistance.
Owner

@ddogfoodd Unrelated, but do you know whether it's possible to set environment variables globally/persistently on Nix? For typical Linux distros, Dove accomplishes this by copying dov-env-overrides.sh file to /etc/profile.d/dove-env-overrides.sh. It'd be great if there was some way we could set environment variables for Nix users as well, will likely become more important in the future.

@ddogfoodd Unrelated, but do you know whether it's possible to set environment variables globally/persistently on Nix? For typical Linux distros, Dove accomplishes this by copying [`dov-env-overrides.sh`](https://codeberg.org/celenity/Dove/src/branch/dev/build-resources/linux/etc/profile.d/dove-env-overrides.sh) file to `/etc/profile.d/dove-env-overrides.sh`. It'd be great if there was some way we could set environment variables for Nix users as well, will likely become more important in the future.
Author
Contributor

I just verified it works for NixOS like this:
They could be set in the flake.nix like this.

Some more information here.

However, there are two things I am unsure about.

  1. I don't know if this behaves differently for darwin or distros other than NixOS when they use Nix.
  2. As the environment variables are used for building the phoenix / dove configs, I think this might not be helpful because the environment variables set this way are active after the next login. I think the build process wouldn't pick them up, only the next build after reboot/logout would. If I'm not missing something this only makes sense for environment variables that are evaluated during start-up or run-time of a program.
I just verified it works for NixOS like this: They could be set in the `flake.nix` [like this](https://codeberg.org/ddogfoodd/Dove/src/commit/5e2ec0f0c7b48ee62ee09e1a2fb7481d42d0aa9e/flake.nix#L65-L67). Some more information [here](https://search.nixos.org/options?channel=25.11&query=environment.variables&show=environment.variables). However, there are two things I am unsure about. 1. I don't know if this behaves differently for darwin or distros other than NixOS when they use Nix. 2. As the environment variables are used for building the phoenix / dove configs, I think this might not be helpful because the environment variables set this way are active after the next login. I think the build process wouldn't pick them up, only the next build after reboot/logout would. If I'm not missing something this only makes sense for environment variables that are evaluated during start-up or run-time of a program.
Owner

@ddogfoodd Thanks for sharing!

The environment variables I'd intend to set this way actually aren't related to the build process, they are used and evaluated by Firefox/Thunderbird at build-time. Currently, they're mainly just used to ex. disable Mozilla's crash reporter, but I'm also looking into adding one to set the OS platform as well, so that we can potentially unify Dove and Phoenix into having one unified .cfg file for all platforms. Since you said these environment variables persist, they should be perfect for this use case. I'll look into adding them!

@ddogfoodd Thanks for sharing! The environment variables I'd intend to set this way actually aren't related to the build process, they are used and evaluated by Firefox/Thunderbird at build-time. Currently, they're mainly just used to ex. disable Mozilla's crash reporter, but I'm also looking into adding one to set the OS platform as well, so that we can potentially unify Dove and Phoenix into having one unified `.cfg` file for all platforms. Since you said these environment variables persist, they should be perfect for this use case. I'll look into adding them!
Owner

Hey @ddogfoodd I've recently made some major changes to Dove and Phoenix's build systems and how they're structured - if you have a chance and don't mind, can you please test installing Phoenix and Dove on Nix from the dev branches? Would like to make sure everything is okay on the Nix side. I did update the Nix files to point to the new paths where relevant, but want to make sure I didn't ex. miss anything and that there aren't any other places causing issues.

Very much appreciated!

Hey @ddogfoodd I've recently made some major changes to Dove and Phoenix's build systems and how they're structured - if you have a chance and don't mind, can you please test installing Phoenix and Dove on Nix from the `dev` branches? Would like to make sure everything is okay on the Nix side. I did update the Nix files to point to the new paths where relevant, but want to make sure I didn't ex. miss anything and that there aren't any other places causing issues. Very much appreciated!
Author
Contributor

Thank you for your continued efforts on improving the build systems and also for keeping Nix users in mind!
I will be able to test and take a look in a few hours.

Thank you for your continued efforts on improving the build systems and also for keeping Nix users in mind! I will be able to test and take a look in a few hours.
Author
Contributor

Looks good to me!
/etc/firefox contains:

  • defaults/pref/phoenix.js
  • phoenix/assets/... with phoenix branding
  • phoenix/specs/... with userjs and permissions for specific services
  • policies/policies.json
  • phoenix.cfg

Files content looks fine as well.
Just in case, that's not wanted behavior, I noticed Help > About now shows Phoenix - Extended.

Looks good to me! `/etc/firefox` contains: - `defaults/pref/phoenix.js` - `phoenix/assets/...` with phoenix branding - `phoenix/specs/...` with userjs and permissions for specific services - `policies/policies.json` - `phoenix.cfg` Files content looks fine as well. Just in case, that's not wanted behavior, I noticed Help > About now shows Phoenix - Extended.
Owner

@ddogfoodd wrote in #59 (comment):

Looks good to me! /etc/firefox contains:

  • defaults/pref/phoenix.js
  • phoenix/assets/... with phoenix branding
  • phoenix/specs/... with userjs and permissions for specific services
  • policies/policies.json
  • phoenix.cfg

Great, thank you for confirming!! I assume it also worked similarly for Dove?

Files content looks fine as well. Just in case, that's not wanted behavior, I noticed Help > About now shows Phoenix - Extended.

Was this on Firefox/Phoenix or Thunderbird/Dove?

@ddogfoodd wrote in https://codeberg.org/celenity/Dove/issues/59#issuecomment-15159159: > Looks good to me! `/etc/firefox` contains: > > * `defaults/pref/phoenix.js` > * `phoenix/assets/...` with phoenix branding > * `phoenix/specs/...` with userjs and permissions for specific services > * `policies/policies.json` > * `phoenix.cfg` Great, thank you for confirming!! I assume it also worked similarly for Dove? > Files content looks fine as well. Just in case, that's not wanted behavior, I noticed Help > About now shows Phoenix - Extended. Was this on Firefox/Phoenix or Thunderbird/Dove?
Author
Contributor

Yes, Dove worked similar.

Firefox shows Phoenix - Extended.
Thunderbird shows just Dove.

Yes, Dove worked similar. Firefox shows Phoenix - Extended. Thunderbird shows just Dove.
Owner

@ddogfoodd wrote in #59 (comment):

Yes, Dove worked similar.

Great, thanks for confirming!!

Firefox shows Phoenix - Extended. Thunderbird shows just Dove.

Hmm, to confirm, did you choose to enable Phoenix Extended/use the specialized config for it? If so, I’d say that’s intended (weird it didn’t show before though), but, if not, that’s indeed a bug/unexpected and something we’ll need to investigate.

@ddogfoodd wrote in https://codeberg.org/celenity/Dove/issues/59#issuecomment-15186666: > Yes, Dove worked similar. Great, thanks for confirming!! > Firefox shows Phoenix - Extended. Thunderbird shows just Dove. Hmm, to confirm, did you choose to enable Phoenix Extended/use the specialized config for it? If so, I’d say that’s intended *(weird it didn’t show before though)*, but, if not, that’s indeed a bug/unexpected and something we’ll need to investigate.
Author
Contributor

@celenity wrote in #59 (comment):

Hmm, to confirm, did you choose to enable Phoenix Extended/use the specialized config for it? If so, I’d say that’s intended (weird it didn’t show before though), but, if not, that’s indeed a bug/unexpected and something we’ll need to investigate.

No, this is without opting for extended. So it shows Extended by default when installed via Nix it seems.

@celenity wrote in https://codeberg.org/celenity/Dove/issues/59#issuecomment-15208110: > Hmm, to confirm, did you choose to enable Phoenix Extended/use the specialized config for it? If so, I’d say that’s intended _(weird it didn’t show before though)_, but, if not, that’s indeed a bug/unexpected and something we’ll need to investigate. No, this is without opting for extended. So it shows Extended by default when installed via Nix it seems.
Owner

@ddogfoodd wrote in #59 (comment):

@celenity wrote in #59 (comment):

Hmm, to confirm, did you choose to enable Phoenix Extended/use the specialized config for it? If so, I’d say that’s intended (weird it didn’t show before though), but, if not, that’s indeed a bug/unexpected and something we’ll need to investigate.

No, this is without opting for extended. So it shows Extended by default when installed via Nix it seems.

I believe I just discovered/fixed the issue, thank you for letting me know! Should now be fixed (as of celenity/Phoenix@d88a82c717).

@ddogfoodd wrote in https://codeberg.org/celenity/Dove/issues/59#issuecomment-15210705: > @celenity wrote in #59 (comment): > > > Hmm, to confirm, did you choose to enable Phoenix Extended/use the specialized config for it? If so, I’d say that’s intended _(weird it didn’t show before though)_, but, if not, that’s indeed a bug/unexpected and something we’ll need to investigate. > > No, this is without opting for extended. So it shows Extended by default when installed via Nix it seems. I believe I just discovered/fixed the issue, thank you for letting me know! Should now be fixed *(as of https://codeberg.org/celenity/Phoenix/commit/d88a82c717c1175dcf9af717af1fa3e1e5e8f1ec)*.
Author
Contributor

@celenity wrote in #59 (comment):

I believe I just discovered/fixed the issue, thank you for letting me know! Should now be fixed (as of celenity/Phoenix@d88a82c717).

Confirmed! Thanks!

@celenity wrote in https://codeberg.org/celenity/Dove/issues/59#issuecomment-15216041: > I believe I just discovered/fixed the issue, thank you for letting me know! Should now be fixed _(as of [`celenity/Phoenix@d88a82c717`](https://codeberg.org/celenity/Phoenix/commit/d88a82c717c1175dcf9af717af1fa3e1e5e8f1ec))_. Confirmed! Thanks!
Owner

@ddogfoodd wrote in #59 (comment):

@celenity wrote in #59 (comment):

I believe I just discovered/fixed the issue, thank you for letting me know! Should now be fixed (as of celenity/Phoenix@d88a82c717).

Confirmed! Thanks!

Thanks for confirming!!

@ddogfoodd wrote in https://codeberg.org/celenity/Dove/issues/59#issuecomment-15290258: > @celenity wrote in #59 (comment): > > > I believe I just discovered/fixed the issue, thank you for letting me know! Should now be fixed _(as of [`celenity/Phoenix@d88a82c717`](https://codeberg.org/celenity/Phoenix/commit/d88a82c717c1175dcf9af717af1fa3e1e5e8f1ec))_. > > Confirmed! Thanks! Thanks for confirming!!
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
celenity/Dove#59
No description provided.