jetify-com / devbox

Instant, easy, and predictable development environments
https://www.jetify.com/devbox/
Apache License 2.0
8.84k stars 210 forks source link

Improve integration between devbox and desktop environments #2273

Open andbleo opened 2 months ago

andbleo commented 2 months ago

What problem are you trying to solve?

devbox advertises itself as a replacement for apt or brew for global package management (https://www.jetify.com/devbox/docs/devbox_global/), but the current support for GUI applications and systemd services is lacking and can give a poor first impression for people coming from other package managers. Here are some issues I ran into as a first time user on a fresh install of Pop!_OS 22.04 LTS with devbox 0.12.0 and the Determinate nix installer 0.25.0. Everything done below was in devbox global.

  1. GUI applications don't show up in the list of applications to launch from the pop os launcher
    • I installed neovim 0.10.1, which has a .desktop file, but it didn't show up in the launcher
    • This was because ~/.local/share/devbox/global/default/.devbox/nix/profile/default/share/ was not added to XDG_DATA_DIRS. I added this myself in my ~/.profile, and after a reboot, I could see the applications. I don't know if this is the correct or ideal solution for this though. If it is, perhaps eval "$(devbox global shellenv)" could also update XDG_DATA_DIRS?
  2. After fixing 1, the GUI applications now appear in the launcher but clicking on them does nothing
    • This was because ~/.local/share/devbox/global/default/.devbox/nix/profile/default/bin was not in the PATH for the Gnome shell. I saw that eval "$(devbox global shellenv)" was adding the devbox global bin path to PATH, but the recommendation was to put that into .bashrc, which Gnome shell doesn't use. When I moved eval "$(devbox global shellenv)" to my .profile and rebooted, I was able to run the GUI applications from the launcher. Unfortunately, this meant that the refresh-global alias was not available in my terminal, so I have a feeling this is not a good solution.
  3. systemctl can't find unit files

    • After installing syncthing 1.27.12, I was able to run it directly from a terminal, but systemctl couldn't find the unit file
    • After much trial and error and googling, I found that you can inject the path to devbox's share directory into the XDG_DATA_DIRS env var that systemctl -- user uses by adding the following to ~/.config/systemd/user.conf (but it will break non-nix systemd user services):

      [Manager]
      # Don't do this
      ManagerEnvironment="XDG_DATA_DIRS=/home/andrew/.local/share/devbox/global/default/.devbox/nix/profile/default/share/"
    • After adding the above, systemctl --user status syncthing.service was able to find the unit file and I could start the service, but this broke other user services (namely, my sound no longer worked, which needed pipewire)
    • Instead, you can systemctl --user --now enable <full_path_to_nix_systemd_unit_file> and avoid the entire problem. Annoying not to be able to refer to unit file by its relative name only, but better than breaking everything else.
  4. Apps that use OpenGL don't work
    • I installed wezterm 20240203-110809-5046fc22, but when trying to run it, I ran into libEGL errors. This appears to be a common problem with nix applications that use OpenGL. I saw https://github.com/nix-community/nixGL but I haven't yet looked into how to integrate that in with devbox. At the very least, I know I can't install it with devbox with a simple devbox global add nixGL.

These are the issues I have encountered trying to run 3 different apps that I installed, so it likely isn't an exhaustive list.

What solution would you like?

If there aren't quick fixes to the problems I outlined above, it would be great to see some updated docs/FAQs explaining the current limitations of devbox as a global package manager and/or some workarounds until the out of the box experience is better. I think devbox has a lot to offer, but I would hate to see people turned away from it immediately if the app they want to use doesn't run correctly.

Alternatives you've considered

Some of these issues I ran into are detailed in a bug here: https://github.com/jetify-com/devbox/issues/2227

00sapo commented 4 weeks ago

Point 2 can be fixed by prepending the Exec line with devbox global run.

I worked around this issue by creating a $HOME/.local/bin/devbox script like this:

#!/bin/env bash

/usr/local/bin/devbox "$@"

for i in "$HOME"/.local/share/devbox/global/default/.devbox/nix/profile/default/share/applications/*.desktop; do
  sed "s/Exec=/Exec=devbox global run /" "$i" >"$HOME"/.local/share/applications/"$(basename "$i")"
done

for i in "$HOME"/.local/share/applications/*.desktop; do
  # take the first word of the Exec= line
  exec="$(grep -oP '^Exec=\K[^ ]+' "$i")"
  # check if the first word doesnt exists as a command in the path
  for exec in $exec; do
    if ! command -v "$exec" &>/dev/null; then
      echo "$i should be removed because $exec doesn't exists"
    fi
  done
done
andbleo commented 4 weeks ago

I switched to zsh, but I ended up running eval "$(devbox global shellenv)" in both .profile and .zshrc. This appears to have worked ok so far.