espanso will only use system-installed interpreters about espanso HOT 6 OPEN

Thanks for the reply, smeech!

Using global variable is indeed my current workaround. Was just wondering if we can set it up outside the matches entirely, as I'm syncing the matches files between platforms.
Your proposed solution using script and read it into global_vars might just be able to solve this issue, I'll look into this.
Thanks again!

from espanso.

Yeah, I would be happy with this hack, but it's not recommended to use the OS default python, especially in Linux environments.
Probably I'm over estimating the importance of this issue, but to use the OS python is something I try very hard not to do.

I'm happy with agreeing a solution and move it to the prioritization queue (the project board). It will be done when it's ready 🚀

from espanso.

I think Pwsh as a shell is coming to Windows. I have it working on Linux, and it appears in the dev branch code alongside the other Windows alternatives.

A workaround for Python for now may be to define a global variable for the interpreter path, depending on the OS. E.g.:

global_vars:
  - name: python # Linux
    type: echo
    params:
      echo: /usr/bin/python

for use in expansions:

  - trigger: :test
    replace: "{{output}}"          
    vars:
      - name: output
        type: script
        params:
          args: ["{{python}}", -c, print("something")]

or

          args: ["{{python}}", /path/to/your/script.py]

for example. But, I can see, one still has to use the absolute path, so that may not help.
Do you need multiple versions of Python on your system?
I suppose you could add pyenv to Windows too, and read it into a global_var using a script on all OSs, with something like:

import os; print(os.path.join(os.getenv("PYENV_ROOT"), "shims", "python"))

?

from espanso.

Ideally one would be able to use filter_os: app-specific configurations, but as only one app-specific configuration can be active at any time it would involve rewriting all you're already using to combine them with filter_os:.

from espanso.

Mmmmmmm. This hack works, but is the definitive solution we want?
It's difficult to achieve a perfect solution here. Python have normally a lot of interpreters, and compiling its own python version is a common task in the ecosystem. What could be done in order to make this easier for users?
One possible solution would be add a line in config.yml called python_interpreter or so. I'm not seeing very good having to specify the python interpreter on each match and passing it to the engine.
What do you think? and another more difficult question: how do we manage libraries? (venvs)

from espanso.

It's not ideal, but it's for a fairly narrow use-case, where someone wants to use a different version than the system standard version, without hard-coding the path (in order to use it across OSs). Unless this is easy to implement, it's unlikely to happen.

from espanso.