check for catalyst_cli in $PATH

[0mWh]

Context: Catalyst could not find itself in an astral-uv installation.

Description of the Change: Search for "catalyst" cli executable on the system path.

Benefits: It works in astral-uv

Possible Drawbacks: Different "catalyst" on the system path?

Related GitHub Issues: This

[dime10]

Hi @0mWh, thank you for contributing to Catalyst! We'll have someone from the team review your PR.

[dime10]

Thank you again for your PR @0mWh! We've had several discussions around it, and came to the conclusion that we'd like to avoid matching against any executable on PATH that just happens to be named catalyst.

What we're proposing is adding an environment variable called CATALYST_EXECUTABLE that can be customized by the user if desired, and raise an error message pointing out this variable as an alternative if Catalyst can't find it's binary like in your case.

Please let us know if that would cover your use-case. Alternatively, if you'd like to provide some additional details about the issue you're encountering (e.g. what the directory structure of your installation is like, including the path to the catalyst binary) we could also look into that.

[0mWh]

Thanks for the questions & sorry for the delay; patching it locally de-prioritized this for me.

---

we'd like to avoid matching against any executable on PATH that just happens to be named catalyst.

I'm not sure what % of cases this would affect. Maybe some mechanism could verify if the catalyst binary is actually your pennylane catalyst? Also, at least in my case, the directory in which catalyst_cli resides is at the front of the PATH anyway.

---

adding an environment variable called CATALYST_EXECUTABLE that can be customized by the user if desired

The problem is that the environment's runtime path can have GUIDs and randomized strings (horrible, I know), so I do not think that this be determined reliably.

---

Please let us know if that would cover your use-case. Alternatively, if you'd like to provide some additional details about the issue you're encountering (e.g. what the directory structure of your installation is like, including the path to the catalyst binary) we could also look into that.

I patched the install on my system to use it here, in cell 4, setup with uv with this pyproject.toml and an overlaid uv env to run jupyter notebooks.

[dime10]

Thanks @0mWh, and no worries!

I had a look at your notebook, but if I'm reading things correctly the binary is installed in an expected location:

'/home/user/work/quadrigems/.venv/bin/catalyst'

Just to be sure I tried replicating your issue with a uv + venv installation, but the path discovery works fine, detecting the .venv/bin/catalyst location in 2 out of the 3 (fallback) locations.

If you have still have the setup it would be really useful to run the following modified lines in the get_cli_path function to help us understand the underlying the problem:

    # Default path
    path = os.path.join(sysconfig.get_path("scripts"), catalyst_cli)
    print("default", path)
    # if os.path.isfile(path):
    #     return path

    # User path
    user_scheme = sysconfig.get_preferred_scheme("user")
    path = os.path.join(sysconfig.get_path("scripts", scheme=user_scheme), catalyst_cli)
    print("user", path)
    # if os.path.isfile(path):
    #     return path

    # Fallback to python location
    path = os.path.join(os.path.dirname(sys.executable), catalyst_cli)
    print("python", path)
    # if os.path.isfile(path):
    #     return path

after modification run with:

from catalyst.utils.runtime_environment import get_cli_path
get_cli_path()

This will allow us to compare which paths catalyst is looking at vs where the binary is actually located in your kind of setup which seems to be difficult to replicate.