search

wyuenho / emacs-pet

Tracks down the correct Python tooling executables from your virtualenvs so you can glue the binaries to Emacs and delete code in init.el
GNU General Public License v3.0
120 stars 14 forks source link

Let user customize conda root, and check env vars. #36

Closed claytharrison closed 4 months ago

claytharrison commented 4 months ago

Following up from https://github.com/wyuenho/emacs-pet/issues/32#issuecomment-2191654912_

Currently it's required for the prefix field to be set in a file's environment.yml in order for pet-virtualenv-root to find the right environment. I don't have this in any of my environment.ymls though, and it's keeping emacs-pet from finding the place where my environments live.
https://github.com/wyuenho/emacs-pet/blob/cc086d91a9e6ab0158335d37a774356414746e17/pet.el#L605C1-L609C155

I could of course add a prefix line, and doing so fixes the issue, but if I'm working on a library that's going to be used by anybody else, that line shouldn't be getting checked into the repo. It would be nice if it were possible to point emacs-pet to the micromamba (or conda, mamba - I assume) root prefix in some other way.

This PR adds a custom variable pet-condaish-root that the user can set to point to whatever folder contains their envs/, and pet-condaish-env-path to check that as well as the environment variables CONDA_ROOT and MAMBA_ROOT_PREFIX before pet-virtualenv-root errors out.

The prefix line in the environment.yml gets priority right now, then pet-condaish-root, and then the environmental variables, though I'm not sure if that's the best order or not.

wyuenho commented 4 months ago

Thanks for the report. I've pushed dc176e5 which doesn't require customization. Let me know if that works for you.

claytharrison commented 4 months ago

Yes it works great, thank you!