[FEATURE REQUEST] Standalone CLI

[YaroKasear]

I just got a first look at this and it looks like it'll be a lot easier for me to work with than AGS.

There is a major problem with this, though. It's only a module, it doesn't work as a standalone Python application. Even the CLI mentioned in the wiki requires invoking this as a module using python -m.

Now, this doesn't seem too big of a problem with most Linux distributions or package managers...

...until you start working with it on Nix or NixOS. Then this "only a module" approach is a major major headache, because by design Nix does not support simply sticking a library in globally and expecting it to work. Many Python modules can still work this way with Nix.

However, because this project uses GObject Introspection, you can't install the module globally and have it work, as a lot of environment variables GIS sets up are not going to be there. Nix documentation and pretty much every guide in the universe for Nix/NixOS would say to make a python module part of a Nix shell... but that's not really practical for a widget system like this where you're not going to be devving with it 99% of the time but having the module running like an application.

End result: Just installing the module and importing fabric results in it complaining about not finding the Gtk namespace because the environment it needs isn't there and won't be there the way it will be in other Linux environments. The only way I can see to get your package to work on NixOS involves a lot of work involving creating a package for your module (As it is not in nixpkgs.) and then create another package that depends on that first package to contain the configuration I'd want to use.

It's a lot of work that could be sidestepped by there simply being an executable Python script available in this package that Nix would be able to wrap properly. Can't wrap a module, can wrap an application.

I'll understand if you WONTFIX on this one since you're probably more interested in supporting Arch, but I imagine this might be a trivial chance if all the script really needs to do is import fabric and run the command line as if it was "python -m fabric," yes?

[muhchaudhary]

Hey, I'm a nixOS user. You're right that you can't simply wrap a python package as a derivation. To get around this, I've made a devshell environment which lives inside my fabric config directory. With nix-direnv installed on your system, loading into a devshell is almost instant and you can invoke it through a shell script. Take a look my repo for how I got that working.

As for the CLI interface, youre right that since fabric a module (and in my case only available inside the dev shell), you can't really use it.

Fabrics CLI though is basically just sending messages through DBus which you can send through any tool for example dbus-send

Here's the simple bash script i use to send commands through dbus to fabric:

#!/usr/bin/env bash

dbus-send --session --print-reply --dest=org.Fabric.fabric  /org/Fabric/fabric org.Fabric.fabric.Evaluate string:"$1"  > /dev/null 2>&1

You're right though, wrapping a python application is much easier than wrapping a module which needs a devshell to properlly link Gobject-introspection stuff. If you have any ideas as to how you could make something like that I'd love to hear it.

Something like how ags is configured on nixOS would be perfect (directing towards a config file which holds your python code)

Some thing to consider though, autocompletions are already broken because of how python handles gobject bindings so this approach will basically require the use of fakegir or gengir to somehow get them back.

https://github.com/muhchaudhary/fabric-nix

[YaroKasear]

Hey, I'm a nixOS user. You're right that you can't simply wrap a python package as a derivation. To get around this, I've made a devshell environment which lives inside my fabric config directory. With nix-direnv installed on your system, loading into a devshell is almost instant and you can invoke it through a shell script. Take a look my repo for how I got that working.

As for the CLI interface, youre right that since fabric a module (and in my case only available inside the dev shell), you can't really use it.

Fabrics CLI though is basically just sending messages through DBus which you can send through any tool for example dbus-send

Here's the simple bash script i use to send commands through dbus to fabric:

#!/usr/bin/env bash

dbus-send --session --print-reply --dest=org.Fabric.fabric  /org/Fabric/fabric org.Fabric.fabric.Evaluate string:"$1"  > /dev/null 2>&1

You're right though, wrapping a python application is much easier than wrapping a module which needs a devshell to properlly link Gobject-introspection stuff. If you have any ideas as to how you could make something like that I'd love to hear it.

Something like how ags is configured on nixOS would be perfect (directing towards a config file which holds your python code)

Some thing to consider though, autocompletions are already broken because of how python handles gobject bindings so this approach will basically require the use of fakegir or gengir to somehow get them back.

https://github.com/muhchaudhary/fabric-nix

I'll check that out!

I eventually did get a package together in my flake. I use snowfall-lib. I've not configured anything yet and there's still work to be done on it, but here is the nix file. Right now all it does is print "Hello World," but it imports the fabric module first to ensure the environment is set up properly. I plan to rename the python file to something better, and have it call a python file in the user's $XDG_CONFIG_HOME and see if I can't do a rudimentary home-manager module for it.

This should allow me to use fabric without dbus-send. Maybe another thing I could do is make he python script engage the CLI with a switch like '--cli' so that a user can use the same script for interacting with the module. I don't know about autocompletion, though.

[its-darsh]

The main idea of not using a standalone executable is that Fabric is meant to be normally used inside a virtual environment. Also, I couldn't think of a good design choice that makes me able to run Fabric configurations (AKA do python ./path/to/config.py), which isn't really necessary.

I'll understand if you WONTFIX on this one since you're probably more interested in supporting Arch

It's not that I'm more interested in supporting Arch; I'm an Arch user, so I had to package Fabric for me and you guys, Arch users. If a person decided to maintain a package of Fabric for whatever distro, I wouldn't complain.

I know no Nix, thus I didn't think of it when writing the project core.

If your main issue(s) were using the CLI, then you can either use the __main__.py file somehow or just use the dbus-send way mentioned by @muhchaudhary.

Finally, I'll not label this issue as wontfix yet my issue here is not the "what", but it's more like the "how", how/what am I supposed to do about it in order to fix it? Suggestions are open.

please ignore my non-existing knowledge in NixOS

[YaroKasear]

The main idea of not using a standalone executable is that Fabric is meant to be normally used inside a virtual environment. Also, I couldn't think of a good design choice that makes me able to run Fabric configurations (AKA do python ./path/to/config.py), which isn't really necessary.

Isn't a python script how you configure and use fabric anyway? Even with a venv isn't that how you're supposed to invoke fabric?

I'll understand if you WONTFIX on this one since you're probably more interested in supporting Arch

It's not that I'm more interested in supporting Arch; I'm an Arch user, so I had to package Fabric for me and you guys, Arch users. If a person decided to maintain a package of Fabric for whatever distro, I wouldn't complain.

Yeah, this is on me. My phrasing was poor. I had more meant that I'll understand if you didn't wish to pursue this due to the underlying reason I am requesting this feature, which is something you don't use or have familiarity with. I apologize.

I know no Nix, thus I didn't think of it when writing the project core.

If your main issue(s) were using the CLI, then you can either use the __main__.py file somehow or just use the dbus-send way mentioned by @muhchaudhary.

Usage of the CLI is secondary, really. The first thought I'm having is in what way one can configure and run a fabric configuration without having to use a venv in a setup where a venv is... perhaps redundant?

Granted this is more my own issue. Nix does have modules for managing venvs, but I wasn't sure how to use them. My current plan is a standalone script that Nix wraps which will handle calls to fabric and imports a user's config.

Finally, I'll not label this issue as wontfix yet my issue here is not the "what", but it's more like the "how", how/what am I supposed to do about it in order to fix it? Suggestions are open.

Well, my only thinking was a simple script like what I'm going to do: An (optional) executable that basically just invokes the module and imports a user's specified python script. This would provide something for Nix to make a wrapper around since it won't wrap modules/libraries, only executables.

But again, that does feel unneeded based on the intent that a user would usually just use a venv and use fabric as a module. More and more I feel like this is PEBKAC.

please ignore my non-existing knowledge in NixOS

No worries.

[its-darsh]

The first thought I'm having is in what way one can configure and run a fabric configuration without having to use a venv in a setup where a venv is... perhaps redundant?

The fact is that Fabric can run inside a virtual environment might be a deal for some people trying to isolate their system-wide Python packages and specific packages to their configuration, this might not be a big deal for Nixers as of my knowledge since you can open an isolated shell