nixos/xdg/xdg-open: init #187293
nixos/xdg/xdg-open: init #187293
Conversation
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/making-xdg-open-more-resilient/16777/8 |
ofborg
bot
added
8.has: package (new)
10.rebuild-darwin: 0
10.rebuild-linux: 1-10
labels
| # due to https://github.com/NixOS/nixpkgs/issues/160923 | ||
| default = "xdg-open-with-portal"; | ||
| }; | ||
| # TODO: |
| --timeout 5 \ | ||
| "" "$targetFile" {} | ||
| fi | ||
| '' |
| { config, pkgs, lib, ... }: | ||
| let | ||
| cfg = config.xdg.xdg-open; | ||
| implementations = { |
There was a problem hiding this comment.
TODO: make this support custom impl packages, this approach isn't great
|
This solves #160923 for Trilium Notes (wrapped electron application) 👍 |
There was a problem hiding this comment.
I don't think duplicating upstream code is a good idea.
We should rather patch the regular xdg-open to handle our FHSEnvs the same as other container runtimes (i.e. flatpak).
We should probably even propose that upstream. Perhaps not in specific to NixOS but for all containerised apps.
Alternatively, we could also just pretend our FHSEnv'd apps are flatpaks.
It isn't really duplicating code? It's a small shell script that always uses the portal, and it's not just for FHS envs, it's also for running under simple wrapper scripts or any other context. It doesn't use any xdg-open code and makes the portal responsible for things 100% of the time. I could make a small repo for it under github.com/LunNova and package it from github instead of including it inline. |
|
I don't see how we're not duplicating upstream code here? We've now got a shell script that is supposed to do the same as upstream xdg-open and even uses the same mechanism internally but we need to maintain it separately. The location of the code is not the problem, the fact that we've got a separate implementation of xdg-open at all is. I think we should instead have a minimal patch that makes xdg-open detect our fhsenvs and treat them the same as flatpak. That's very simply to do. Perhaps even propose that patch upstream so we don't have to maintain it downstream. Building a new implementation of xdg-open and then globally(!) switching it out to fix a bug in fhsenvs is not sustainable in my eyes. |
|
In general being able to replace the version of xdg-open on your system with something not from xdg-utils is useful. There's also handlr and xdg_open_ng, it's not unusual to want to swap your xdg-open implementation. Having a shell script called 'xdg-open' on path is the API that programs expect, and xdg-utils is not the only source of an implementation of it in the wild. In my mind "xdg-open-with-portal" is a package that provides the Separately, it'd be good to get xdg-utils to support some env var to tell it to always use the portal to open things, and to add support for opening files through the portal, but I don't think that should prevent adding a nixos module which controls which implementation of xdg-open you have on your PATH, or that it should prevent having a simple shell script impl of xdg-open that uses the portal. |
|
Raised https://github.com/freedesktop/xdg-utils/pull/12 upstream to add an env var to tell |
|
@Atemu how do you feel about including https://github.com/freedesktop/xdg-utils/pull/12 in nixpkgs in a separate PR before it gets merged? xdg-utils seem very slow to respond to PRs. |
|
I'd make it a patch behind a flag. |
wegank
added
2.status: stale
stale
bot
removed
the
2.status: stale
This repository no longer exists, and I don't see a matching MR on https://gitlab.freedesktop.org/xdg/xdg-utils. |
|
@bb010g it was this commit: LunNova/xdg-utils@123e8ce |
|
Closed in favor of #197118 |
Description of changes
Potential fix for #160923 although is not currently enabled by default.
MERGED
Until #181171 gets merged, this relies on enabling an overlay for all those packages to actually use the xdg-open implementation from the path.Many other packages rely on it implicitly without adding it in a wrapper so will work already without the overlay.Some other things like the steam FHS env also require the overlay currently. Could get them to pick it up from the PATH in a subsequent PR?
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes