+github.com/essembeh/gnome-extensions-cli

[felipecrs]

A very useful tool to manage GNOME extensions.

https://github.com/essembeh/gnome-extensions-cli

[felipecrs]

For some reason I don't know yet, gext from pkgx doesn't work (gext --version works but pretty much anything else like gext list does not).

Because of gsettings:

❯ gext list
No schemas installed
💥 Error: Command '['gsettings', 'get', 'org.gnome.shell', 'enabled-extensions']' returned non-zero exit status 1.
Traceback (most recent call last):
  File "/home/felipecrs/.pkgx/github.com/essembeh/gnome-extensions-cli/v0.10.1/venv/bin/gext", line 6, in <module>
    sys.exit(run())
             ^^^^^
  File "/home/felipecrs/.pkgx/github.com/essembeh/gnome-extensions-cli/v0.10.1/venv/lib/python3.11/site-packages/gnome_extensions_cli/cli.py", line 116, in run
    raise error
  File "/home/felipecrs/.pkgx/github.com/essembeh/gnome-extensions-cli/v0.10.1/venv/lib/python3.11/site-packages/gnome_extensions_cli/cli.py", line 108, in run
    handler(args, manager, store)
  File "/home/felipecrs/.pkgx/github.com/essembeh/gnome-extensions-cli/v0.10.1/venv/lib/python3.11/site-packages/gnome_extensions_cli/commands/list_.py", line 47, in run
    enabled_uuids = manager.list_enabled_uuids()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/felipecrs/.pkgx/github.com/essembeh/gnome-extensions-cli/v0.10.1/venv/lib/python3.11/site-packages/gnome_extensions_cli/filesystem.py", line 110, in list_enabled_uuids
    stdout = subprocess.check_output(
             ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/felipecrs/.pkgx/python.org/v3.11.9/lib/python3.11/subprocess.py", line 466, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/felipecrs/.pkgx/python.org/v3.11.9/lib/python3.11/subprocess.py", line 571, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['gsettings', 'get', 'org.gnome.shell', 'enabled-extensions']' returned non-zero exit status 1.

❯ gsettings get org.gnome.shell enabled-extensions
@as []

❯ pkgx +gext env gsettings get org.gnome.shell enabled-extensions
No schemas installed

Refs felipecrs/dotfiles#111

[jhheider]

probably needs companions: gnome.org/glib: '*'.

no, actually; looks like glib needs to know where to find the schemas.

[felipecrs]

Just found out:

❯ pkgx +gext env bash -c 'unset XDG_DATA_DIRS && gsettings get org.gnome.shell enabled-extensions'
@as []

❯ pkgx +gext env bash -c 'gsettings get org.gnome.shell enabled-extensions'
No schemas installed

[felipecrs]

I compared my env with pkgx +gext env and found out that the latter has XDG_DATA_DIRS=/home/felipecrs/.pkgx/gnu.org/coreutils/v9.5.0/.

Then unsetting it works.

I'm not sure what's the way forward though.

[jhheider]

i've got fixes to load in gsettings and schemas, but org.gnome.shell isn't available. it looks like https://gitlab.gnome.org/GNOME/gnome-shell provides it, so that'd need to be packaged.

[felipecrs]

Hm... but I expect gext to work against my system's GNOME, so I believe gsettings should also load schemes from system.

If you package schemes by yourself, there's a chance schemes are for a different GNOME version than the one my system is using.

[jhheider]

that's a good point. does it work if you do SCHEMADIR=/usr/share/glib-2.0/schemas gext list?

[jhheider]

there's always going to be weird issues integrating pieces of large systems via a system like pkgx's.

[felipecrs]

that's a good point. does it work if you do SCHEMADIR=/usr/share/glib-2.0/schemas gext list?

Same issue.

But this works:

❯ pkgx +gext env bash -c 'XDG_DATA_DIRS="$XDG_DATA_DIRS:/usr/local/share/:/usr/share/" gsettings get org.gnome.shell enabled-extensions'
@as []

So, I think pkgx could be improved to add some sensible defaults like /usr/local/share/:/usr/share/ to its generated XDG_DATA_DIRS when none is set prior to its execution.

But this would be a change in libpkgx I suppose.

[felipecrs]

That's because:

When XDG_DATA_DIRS is set (pkgx's case), gsettings will try loading schemes from it (or something like that). When it's not set (default in Ubuntu distro), gsettings will fallback to XDG_DATA_HOME then some system-known others.

So I just think pkgx should be extra careful when overriding XDG_DATA_DIRS to ensure applications won't stop looking at XDG_DATA_HOME when XDG_DATA_DIR is unset prior to execution.

[felipecrs]

But yeah, this isn't simple at all.

[jhheider]

overriding users' XDG_* env vars isn't likely to pass muster. those should be strictly managed by the user. we alter them in build scripts to facilitate building, but I don't see any runtime configuration in the pantry that alters them.

it's possible mxcl might accept a fallback value, but iirc those are described in the spec itself.

[felipecrs]

Oh. Maybe we have a bug in pkgx then?

❯ env | grep XDG
XDG_RUNTIME_DIR=/run/user/1002/

❯ pkgx env | grep XDG
XDG_DATA_DIRS=/home/felipecrs/.pkgx/gnu.org/coreutils/v9.5.0/share
XDG_RUNTIME_DIR=/run/user/1002/

If pkgx was not supposed to alter XDG_ vars in runtime, then it was not supposed to inject XDG_DATA_DIRS either, I suppose.

[felipecrs]

https://github.com/pkgxdev/pkgx/blob/8b6c3671290cde1a47ba975254a58ad9eff80fce/src/prefab/construct-env.ts#L61

[jhheider]

Interesting. So, it adds to it, which means if it's unset that could cause problems. Very interesting. I wonder what problem that was added to solve.

[felipecrs]

To make sure this doesn't go to limbo, would you reopen this issue?

[jhheider]

i don't think this is the correct issue; i've opened one to add gnome-shell, which might fix your issue, assuming the schemae don't mismatch. i'll open a discussion on libpkgx about the XDG_ issue.

[felipecrs]

Thanks a lot!