[Preview] Python Executable Tracker for Emacs

Hi everyone! I've written a new package to track down the correct Python executables from the various virtualenvs that you might create for your Python projects. In short, the motivation for this package is that modern Python projects typically rely on a bunch of linters and formatters, and they can all be installed in different virtualenvs. This package will find those installed in `pre-commit`, then `poetry`, and then finally whatever is on your `exec-path`, and then assign the absolute paths to many of the [supported Emacs package](https://github.com/wyuenho/emacs-pet#supported-emacs-packages) variables. The full list of supported virtualenv tools is [here](https://github.com/wyuenho/emacs-pet#supported-python-virtual-environment-tools). This package is in early preview, but it's perfectly usable for most situations by my estimate. If you run into any problems, please don't hesitate to file an issue on the repo. Also, if you have any idea about writing tests for this package without having me creating all kinds of a fixtures or mocking dozens of things, please let me know! [https://github.com/wyuenho/emacs-pet](https://github.com/wyuenho/emacs-pet)

I would suggest supporting also `pipenv`, it is a rather common alternative to `poetry`. And also plain old `venv` - usually in `.venv` or `venv` subfolder.

and there's also pdm .... It's painful just thinking about supporting them...

Thanks for the suggestions! Supporting plain old `venv` shouldn't be too hard, although it's already somewhat supported by way of `direnv`. `pipenv` tho, this thing never should have existed and I personally hate it, so I'd like to do my part to hasten its demise :P Just kidding. Supporting it isn't too difficult, I'll probably do it on a weekend.

Yeah... and flit... I'm not gonna touch both of them unless there's a feature request and there are enough votes. It's not that hard to support them, it's just I don't want to put effort into something neither I or somebody else use.

btw does pet accept override from directory or buffer local variables? that's another dimension of complexity.

Care to elaborate?

Second thought, I've just pushed support for `pipenv`, `pdm`, `.venv` and `venv`, see if it works for you.

Oh wow, this looks like it could be super helpful. I write a lot of Python for my day job and environment management is legitimately the worst thing about it - I've written a bunch of hacks myself to try and make things a little nicer, but this looks a million times better already. I'll see if I can take a proper look tomorrow!

Yeah `pipenv` is a pain but I happen to have a project at work using it, so it would be quite useful to have it supported :) I have tried to do something similar to what you are doing with `pet` but I have never managed to convince `pyright` to start from the virtual environment set up by the `pyvenv` package. I have tried to use `pyvenv` to activate the virtual environment first and then restart `pyright` but it doesn't work properly :(

Excellent, thank you! Will have a look.

How is this different from writing a .envrc file and have Emacs obey it with a suitable package (envrc, direnv.el, buffer-env, etc.)?

The difference is you don't even need to sprinkle .envrc files in your Python projects and the executable variables will still be set up correctly in Emacs. Depending on how you use direnv, the difference maybe figuring out how to put the correct executables into your PATH many times, many of which vary slightly, or once and for all in your Emacs init.el. In addition, if you don't want to reconfigure all of your projects that are using direnv etc, you can still use envrc/direnv.el/buffer-env and `pet` will still Just Work™️. `pet` is basically a Do What I(You) Mean package for tracking down executable paths. If it doesn't do what you want, it's probably a bug. P.S. I'll add your buffer-env package into the README, since it just modifies `exec-path`, `pet` works with anything that modifies `exec-path` seamlessly.

I see. FWIW, buffer-env is configured to look for .envrc files by default but it supports other project management tools (for instance, Guix). To configure it for Poetry, you just need to provide a shell command that takes a pyproject.toml file as argument and prints out the corresponding exported env vars.

Reporting back - using this with both `poetry` and `.venv` (haven't tested the `Pipenv` project yet) and it does work nicely. Nice job, thank for fixing this `Python` tooling mess!

Hello, a second report. I have actually discovered that the `poetry` detection isn't working right. I have opened an issue on Github with the details.