Desktop integration (linux)

[eliotb]

I was helping someone to install "spyder" the GUI IDE on linux. The installation goes fine and the app can be run by typing "spyder" in a terminal, but it is not available in the list of applications in the gui desktop (gnome in this case).

Looking inside the .local/pipx/venv/spyder, it comes with the required pieces to enable desktop integration.

• share/applications/spyder.desktop
• share/icons/spyder.png
• and more, not sure if required

Linking these two files into their respective locations inside .local/share enables the application to appear in the gnome app selector. I kind of see this as an extension of the idea of linking the binary into .local/bin

I'm not sure if this is within scope for pipx, either as part of install possibly with option e.g. --desktop-integration, or as a separate command. I don't know if there is something similar for windows and mac...

This may be slightly related to #711.

[uranusjr]

Unfortunately Python packaging does not deal with desktop integration, so this is by-trade out of pipx's scope. You need a "proper" Linux package manager to achieve this (e.g. APT or Yum depending on your distribution of preference). So you need to ask Spyder to package alternative distributions for those functionalities.

#711 is not related; gui-scripts are only relevant on Windows (it's related to how Windows distinguish between "console mode" and "GUI mode" programs) and have no functional differences to console-scripts on POSIX platforms.

There are some discussions on this (in a broader scope) on Discourse but I don't see the idea gaining much traction. It is fundamentally not particularly compatible with language-specific packaging (not just Python) IMO.

[eliotb]

From what I can see, spyder's setup.py does deal with desktop integration. I.e. it puts the expected files into .../share/... . Its just that with pipx, this is inside the venv instead of in the usual place.
So i'm talking about linking these out of the venv to the usual spots in the same way that happens for the binary

[uranusjr]

That's basically what's discussed in the Discourse thread I linked to, and from what I can tell the concensus is that package shouldn't be able to install outside a virtual environment.

I guess the best pipx can do is to copy those files to somewhere like ~/.local/pipx/usr/share (specific location TBD). Would that be enough for you?

[uranusjr]

(And we can make that path configurable so you can point it to your ~/.local/share if you want.)

[eliotb]

yes, basically that. I read the discourse comment, one thought is that part of the purpose of pipx is to make a binary inside a virtual env (appear to be) available outside that venv.
On the side of not doing anything at this point, I'm basing my idea off only one example of a gui app (spyder), it makes sense to find a few more before expending effort on coding. Maybe just documenting how to do it manually would be enough.
Thanks.

[demberto]

@eliotb You should take a look at desktop-app. I only needed my GUI application to show its own icon instead of showing the Python application, but you can do stuff like add shortcuts etc.

[gaborbernat]

IMHO out of scope for this project.

[callegar]

A major pain point here is not due to pip nor pipx. It is that the Wayland protocols do not support some things that X11 used to support and that are taken for granted in other OSes. Specifically, Qt's setWindowIcon is broken on Wayland and a similar functionality cannot currently be obtained in other toolkits either. In other words, currently Wayland pretends that there is a .desktop file for a GUI application to get its own taskbar icon. Unfortunately, there is no way to augment the list of places where the DE looks for icons, desktop files, etc in the same way in which PATH, MANPATH etc. can be augmented. Which basically mean that virtual envs cannot support these things.

While all this may not be an issue for pip and virtualenvs, IMHO for pipx the situation is slightly different. In fact, pipx is meant to touch suff out of the virtual environments and specifically to touch stuff in .local, to expose the entry points of packages in .local/bin. At this point, one may wonder why not also exposing the .desktop file and icon in .local/share via symlinks when available, possibly having this ability controlled by a command line parameter.