Linux launcher

[hmaarrfk]

Is there an interest in adding a linux desktop launcher for spyder? I've had some success creating one for my own application and was wondering if you wanted one for spyder as well.

[ccordoba12]

Sure, that's fine for me. Thanks for offering your help @hmaarrfk!

[hmaarrfk]

The general strategy is one that uses a post-install script to create the appropriate desktop file in ~/.local/share/applications.

The challenge i'm having now, is that every different environment should ideally have different WMClass so that the linux desktop can distinguish them.

I have few strategies in mind, but i hoep to have something for a PR in sept.

Thanks for considering.

[ccordoba12]

The challenge i'm having now, is that every different environment should ideally have different WMClass so that the linux desktop can distinguish them.

Good thinking. I was about to suggest the same.

[hmaarrfk]

from pathlib import Path
import sys
print(Path(sys.executable).parent.parent.name)

is a pretty good way to get the environment name.

It also gets something more than "base" (which is rather non-sensical) if the user installs it in the base environment.

Do you think that is a good way to meaninfully communicate which environment spyder is from?

[ccordoba12]

Yes, I think that's good.

[hmaarrfk]

Remains to think about what happens without conda.

As in, with system installers. Those might end up pointing to usr, or usr local

[ericpre]

Since conda uses https://github.com/ContinuumIO/menuinst on windows to create the start menu sort cut, would it make sense to improve linux support in menuinst, so that it can be used more generally?

[ccordoba12]

Yes, that's what you should do, i.e. add support for desktop files on Linux in menuinst.

[hmaarrfk]

@ccordoba12 so I've been experimenting for a while and I figured I would report:

1. You really want to create an entry-point that activates the conda environment. https://github.com/chrisjbillington/desktop-app/ does this.
2. If you want a per-environment WMCLASS you have to rewrite the argv argument of the application. Desktop App does this to an extent. I think it is rather hacky and not very explicit, but it does work.

Finally, you need to add post-install and pre-unlink scripts if you want to create nicer launchers.

I'm happy to share mine, but I think my post-link scripts are too complicated.

In either case, I'm not sure spyder is too keen on an other dependency.

I wish there was a way for me to:

import conda
env_name = conda.detect_env_name()

[ccordoba12]

You're welcome to open a pull request so we can take a look at your work.

[hmaarrfk]

ok. I'll see what it can do. I'll have to test it with potentially some Spyder source code modifications so I'll see what time i can scrounge up this weekend.

[hmaarrfk]

I think some small modifications might be good on the spyder source:

https://github.com/ramonaoptics/spyder-desktop-feedstock/blob/main/recipe/post-link.sh#L40

The .desktop file should be modified to use full paths since conda installed files aren't in typical search paths.

Finally, you can add a line like:

desktop-file-install --dir="${DESKTOP_FILE_DIRECTORY}" "${CONDA_SPYDER_DESKTOP}" || exit 0

This has the effect of erasing any spyder.desktop file in your DESKTOP_FILE_DIRECTORY. This is probably more appropriate for a separate package to do.

It would be good if we could get the patching done as part of the conda-forge recipe.

I've tried exprimenting with being explicit in the launcher about which environment spyder was installed in. It turned out to be pretty confusing for users.

The current implementation doesn't add the conda prefix to the PATH. Ideally, you would use conda run --prefix ${PREFIX} but I can't guarantee that the user will have conda in a known location.

You could use:

Exec=${PREFIX}/bin/conda run --prefix ${PREFIX} ${PREFIX}/bin/spyder %F

but that requires you to depend on conda in your environment.

I'm not sure I know how to pull the location of the "conda" used to create environments safely.

[hmaarrfk]

For what its worth, I added conda to my dependencies, I'm just not sure it is the "right" thing to do for conda as a whole.

[mrclary]

@ccordoba12, can this issue be closed when we release Spyder 6.0.0?

[ccordoba12]

I think this depends on a new menuinst version to apply to our conda-forge package. What we'll have in Spyder 6 will only be useful for people that use our own installer.

[mrclary]

At present, menuinst only works for Windows. A forthcoming version of menuinst will work for Windows, macOS, and Linux. Our installer is using this development version of menuinst. However, our installer build routine modifies this feedstock to accommodate the new menuinst. So I have the following questions:

• Does anyone currently use the menu feature of this feedstock? Does it even work?
• Should we just update this feedstock with the changes needed for our installers? Maybe when cep-devel is merged?

[ccordoba12]

Does anyone currently use the menu feature of this feedstock? Does it even work?

I think it works on Windows.

Should we just update this feedstock with the changes needed for our installers?

Yeah, we should do that.

Maybe when cep-devel is merged?

Right. When there's a new version of menuinst that includes those changes, then we could update this feedstock.

[mrclary]

@ccordoba12 @hmaarrfk, I think this issue can be closed. New releases of menuinst are now available and are accommodated in this feedstock.

[ccordoba12]

Yep, we can close this one now.

[hmaarrfk]

Cools stuff!!!