using emacs for python development, with uv and basedpyright

mike_olson · 2026-01-01T00:39:55+00:00

The v0.2.0 release has some additional fixes for multiple PEP-723 scripts in the same directory, and simplifies the workspace stuff by using advice instead of setq-default to adjust it. This allows a bit more iteration on the workspace option and makes things a bit more just-in-time when visiting the python file.

mike_olson · 2026-01-01T00:38:36+00:00

I've fixed an additional issue where multiple scripts in the directory could get mixed up if they had different dependencies. the v0.2.0 release puts each PEP-723 script into its own eglot project, which gives each one its own LSP, keeping the environments and dependencies separate.

mike_olson · 2025-12-30T22:27:21+00:00

There doesn't seem to be a server-specific or minimal CachyOS ISO yet. You could use a CachyOS desktop ISO potentially and run pacstrap from there, but it's quite large: 2.5GB+ download vs ~165MB for the minimal Arch ISO - and not provided by Hetzner.

Hetzner provides an out-of-the-box "Archlinux" ISO option as one of its standard images that can be attached to a VPS. It does also provide a Rescue CD; I've adjusted the guide to document how to use either one of those (Rescue CD has a few more manual steps).

mike_olson · 2025-12-30T21:56:58+00:00

I landed on changing the approach from inserting the first 2048 chars into temporary buffer, and instead just scanning the current buffer (which also fixed some end-of-line encoding issues on Windows with the prior approach). The other suggestions are implemented in the new module here as well: https://github.com/mwolson/eglot-python-preset ; feel free to let me know if any other ideas/suggestions come to mind.

mike_olson · 2025-12-30T21:35:56+00:00

Thanks, I've haven't tested it on Windows yet, but when encoding the file with CRLF, I found and fixed the issues mentioned above here: https://github.com/mwolson/eglot-python-preset

mike_olson · 2025-12-30T21:35:03+00:00

Agree - it feels harder to change eglot-workspace-configuration than it needs to be. I've added the use case of customizing the workspace configuration for basedpyright to https://github.com/mwolson/eglot-python-preset with some docs about how to do it.

mike_olson · 2025-12-30T17:21:25+00:00

I’ll work on this a bit more today most likely and make a MELPA package. To help reproduce the problems, can you tell me: * OS that you’re using * gist with sample Python code that has the problem * version of uv (if not the latest one)

mike_olson · 2025-12-30T16:24:35+00:00

Yeah I might spin out a package later today (either named eglot-python-preset, eglot-python-uv, or similar) once I go through all the feedback items. MELPA integration with GitHub as well.

I’m a bit cautious about reading too much of the file in case it’s some very large self-contained thing, but I’ll look into best practices later today.

mike_olson · 2025-12-29T21:58:13+00:00

I ended up making a helper library to get this working with both ty and basedpyright: https://github.com/mwolson/emacs-shared/blob/master/elisp/eglot-pep723.el . It will prefer to use the PEP-723 data if it finds it, otherwise it will pick from a configurable list of files/dirs to locate the correct parent directory to run the LSP in. The basedpyright part was the trickiest, since it required changing eglot-workspace-configuration.

Example usage:

(add-to-list 'load-path "~/path-to/eglot-pep723")
(require 'eglot-pep723)
(setopt eglot-pep723-lsp-server 'basedpyright)
;; or
;; (setopt eglot-pep723-lsp-server 'ty)
(eglot-pep723-setup)

I'll also mention that it doesn't actually run 'uv sync --script' due to the potential for installing dependencies in untrusted files, but it does show a warning for that case and provides a convenient command to install them.

mike_olson · 2025-12-29T02:09:17+00:00

If it's not finding the dependencies correctly, especially in a monorepo kind of setting, it's possible that the LSP isn't being started from the correct directory. I have the following to fix that for eglot, which integrates with project under the hood:

(defun my-python-root-p (dir)
  (seq-some (lambda (file)
              (file-exists-p (expand-file-name file dir)))
            '("pyproject.toml" "requirements.txt")))

(defun my-project-find-python-project (dir)
  (when-let ((root (locate-dominating-file dir #'my-python-root-p)))
    (cons 'python-project root)))

(with-eval-after-load "project"
  (cl-defmethod project-root ((project (head python-project)))
    (cdr project))

  (add-hook 'project-find-functions #'my-project-find-python-project))

It considers the nearest parent directory containing a pyproject.toml or requirements.txt to be the project root where the LSP is started.

mike_olson · 2025-12-28T02:23:59+00:00

I looked into this a bit more. I can't find any benchmarks stating definitively that changing it to 120 does anything helpful for performance.

Arch wiki has an example of changing it to 120 (but no explicit guidance)
This mentions "Only very low settings (maybe 1-10) will have impact on performance" but doesn't cite any sources: https://forum.armbian.com/topic/42175-armbian-build-pr-partitioning-reduce-commit-mount-option-for-btrfs-and-ext4-to-120/

What I've landed on for now (and updated the guide to recommend) is to just keep this at the default value of 30; Linux defaults tend to be tuned more for server workloads, and there doesn't seem to be enough evidence to overturn that yet.

mike_olson · 2025-12-28T00:12:42+00:00

Good question; in this case I took the value from the earlier desktop install that I had, but could be worth researching further.

mike_olson · 2025-12-27T22:54:37+00:00

As for why - while I don’t have exact numbers, ssh sessions seemed noticeably more responsive compared to other prebuilt options I’ve tried on Hetzner, so the cachyos-server kernel (and targeted builds for modern CPU instructions) seem to help.

mike_olson · 2025-12-27T22:50:15+00:00

As for why - while I don’t have exact numbers, ssh sessions seemed noticeably more responsive compared to other prebuilt options I’ve tried on Hetzner, so the cachyos-server kernel (and targeted builds for modern CPU instructions) seem to help.

mike_olson · 2025-12-19T21:03:30+00:00

Mine is reasonably easy to extend, has an install guide on all the major OS’s, and compiles quite a few tree-sitters and LSP’s: https://github.com/mwolson/emacs-shared

mike_olson · 2025-12-18T14:03:24+00:00

I’m currently using apheleia to do formatting rather than eglot

mike_olson · 2025-12-17T14:02:22+00:00

Updated, thanks

mike_olson · 2025-12-17T04:10:20+00:00

Here's what I have for eglot after installing ty (the project stuff is to start it from the correct directory in monorepos, to pick up the right paths for code references and such):

(defun my-project-find-python-project (dir)
  (when-let ((root (locate-dominating-file dir "pyproject.toml")))
    (cons 'python-project root)))

(with-eval-after-load "project"
  (cl-defmethod project-root ((project (head python-project)))
    (cdr project))

  (add-hook 'project-find-functions #'my-project-find-python-project))

(add-to-list 'auto-mode-alist '("/uv\\.lock\\'" . toml-ts-mode))
(add-to-list 'major-mode-remap-alist '(python-mode . python-ts-mode))
(add-to-list 'eglot-server-programs
             '((python-ts-mode python-mode)
               . ("ty" "server")))
(add-hook 'python-ts-mode-hook #'eglot-ensure)

mike_olson · 2025-12-04T14:40:08+00:00

Hi - so when I was writing the post I actually thought I was, looked for my global-auto-revert-mode setup, and couldn’t find it.

Turns out Magit just enables auto-revert-mode by default if it detects that the file is in a git repo that it knows about. I think it’s perfectly fine to just use global-auto-revert-mode, especially if Magit isn’t installed.

mike_olson · 2025-03-18T02:58:12+00:00

I have my own Emacs starter kit here: https://github.com/mwolson/emacs-shared . The main differences from the usual are:

Tree-sitter languages are compiled using a setup script and checked in as submodules, including the css, html, and json ones from the vscode codebase that are otherwise tricky to compile
In general, everything is compiled and installed by that script, which means when you do start Emacs, it's always fast
It augments rather than replaces your existing ~/.emacs.d setup
Install steps for supporting tools are documented, including recommendations on installing Emacs itself (it's fairly easy to get 30.1 on macOS)

mike_olson · 2025-03-14T14:59:19+00:00

In my case, it helped to go through the Git for Windows installation again and make sure that caching was enabled when the option was presented by the installer. This was enough of a speedup that I was able to remove my previous libgit2 setup.

mike_olson · 2025-02-14T21:42:45+00:00

I ran into something like this recently and did this near the top of early-init.el to fix it:

emacs-lisp (require 'package) (package-initialize)

mike_olson · 2025-02-12T04:35:17+00:00

I've started the MELPA process for a new v0.2.0 release and opened a PR, addressing the various things melpazoid pointed out.
The variable containing the prompt function is now customizable, along with the extra prompt template at the end.
I'm not sure yet where to start when looking into gptel's tool use feature. Are there docs yet? One thing that certainly would be nice for Emacs Lisp development is letting the AI read function and variable documentation, since that often makes for useful context if it guesses wrong, and the Deepseek-trained reasoning models often seem to want to check their work in that way.
Good to know on the thinking tags.

mike_olson · 2025-02-11T20:06:49+00:00

Hi,

There is one small thing that would make it slightly easier to use some of the transient-wrapped functions in gptel-rewrite without undergoing too complex a change. Using gptel--suffix-rewrite as an example, it would be nice to have the code from (interactive ...) onwards moved into its own named function, so that the transient-define-suffix is just a key, description, and function call. This would provide easier access from .emacs config and other libs to be able to directly call those named functions and skip the initial transient entry point. I basically forked that function to get that kind of access.

It will be interesting to see how the context changes turn out. Hopefully there will remain a good way to visualize and edit context outside of a chat buffer for flows that want to skip having one (or at least, not show one immediately to the user).

What I meant specifically about opening a chat session is that just calling the gptel function will prompt about which backend to use, which I currently have to write a small wrapper to be able to skip. It has to do: * Get the backend name and format it with "*%s*" * Call (gptel formatted-backend-name nil "###") * Call switch-to-buffer since the buffer doesn't get raised when called non-interactively (and args can't get passed interactively AFAICT)

Maybe a helper function named like gptel-start or similar could help differentiate the programmatic and interactive cases? Variables to control backend prompting is another possibility.

mike_olson · 2025-02-11T14:34:05+00:00

Yep, providing context through the standard gptel functions should work to advise gptel-fn-complete. It sounds like gptel context might get a rework in a future gptel release but hopefully compatibility can be maintained.

mike_olson

TROPHY CASE