Migrate Python library to uv

[paulgb]

It's fast and seems to be the direction Python projects are going. We also now spin up a server for each test, for better isolation. This required some changes to the piping on the server side, to allow us to use port 0 to get the OS to assign an available port. This means we need to compute the connection string after we have bound the port, so that the connection string contains the actual bound port and not port 0.

This also sets up Python tests to run in CI/CD, but only when the Python code changes (at least for now).

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
y-sweet-gendocs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 2, 2024 5:36am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
y-sweet-debugger	⬜️ Ignored (Inspect)	Visit Preview		Dec 2, 2024 5:36am
y-sweet-demos	⬜️ Ignored (Inspect)	Visit Preview		Dec 2, 2024 5:36am

[standard-input]

No issues flagged.
Standard Input can make mistakes. Check important info.

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 5eb05c3 in 5 seconds

More details

• Looked at 33 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. python/pyproject.toml:34

• Draft comment:
  The 'dev' dependency group is missing some dependencies that were present in the original 'dev' section, such as 'build', 'twine', and 'ruff'. Consider adding them back to ensure the development environment is fully equipped.
• Reason this comment was not posted:
  Comment did not seem useful.

Workflow ID: wflow_HiJqvxN8P7H0VNAp

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

❌ Changes requested. Incremental review on de5891c in 1 minute and 11 seconds

More details

• Looked at 540 lines of code in 9 files
• Skipped 0 files when reviewing.
• Skipped posting 0 drafted comments based on config settings.

Workflow ID: wflow_O8LfDGw1xqxZZcZe

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 9c273b3 in 4 seconds

More details

• Looked at 37 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. .github/workflows/python-tests.yml:19

• Draft comment:
  The version actions/checkout@v4 does not exist. Consider using actions/checkout@v3.
• Reason this comment was not posted:
  Comment did not seem useful.

Workflow ID: wflow_c9Da1djJxzmpTGyz

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 6d2048a in 9 seconds

More details

• Looked at 37 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. python/tests/server.py:14

• Draft comment:
  self.connection_string should be initialized to None to avoid potential AttributeError.
• Reason this comment was not posted:
  Comment was not on a valid diff hunk.

Workflow ID: wflow_gRtLBKLMTpsx9uER

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[michaelsilver]

I’m a fan of all of it sans migrating to uv. It’s a good tool and seems to be having a moment, but I’m a fan of using boring technologies. I don’t see a need to change build tooling right now. From what I can see, the rest of this PR adds useful functionality, independent of build system

[paulgb]

I’m a fan of all of it sans migrating to uv. It’s a good tool and seems to be having a moment, but I’m a fan of using boring technologies. I don’t see a need to change build tooling right now. From what I can see, the rest of this PR adds useful functionality, independent of build system

I generally agree, but IMHO there are no “boring” package managers for Python, instead there's a mishmash of tools that have never worked well for me. Prior to introducing uv, developing on this library was a pain because you had to set up a virtualenv, install the dependencies, and remember to activate the virtualenv before running tests. Despite being newer, uv already feels like a more mature product than others in the python ecosystem, e.g. I referred to the docs while doing this and they are solid.

[michaelsilver]

developing on this library was a pain because you had to set up a virtualenv, install the dependencies, and remember to activate the virtualenv before running tests.

This is how Python development has been done for a decade, I’m honestly confused why suddenly it’s an issue. I’m happy to sit down and help get you setup if you’re running into issues, but here’s a very quick reference. On the flip side, I see wasted time in migrating and learning a new tool.

(EDIT: In case you’re following the guide, note that M-series Macs use /opt/homebrew instead of /usr/local — you can copy my config here)

[paulgb]

developing on this library was a pain because you had to set up a virtualenv, install the dependencies, and remember to activate the virtualenv before running tests.

This is how Python development has been done for a decade, I’m honestly confused why suddenly it’s an issue. I’m happy to sit down and help get you setup if you’re running into issues, but here’s a very quick reference. On the flip side, I see wasted time in migrating and learning a new tool.

(EDIT: In case you’re following the guide, note that M-series Macs use /opt/homebrew instead of /usr/local — you can copy my config here)

It's not that it's suddenly an issue; Python dependency management has always been a mess, there's no “boring” track to fall back on. pyproject.toml has only been around as a fleshed-out spec for ~4 years, so most of the tooling is still built for a pre-pyproject.toml world.

If we are going to be running tests in CI, I want to use lockfiles, which pip does not natively support. The official tool recommendations from the Python packaging authority for lockfiles are pip-tools and pipenv, both of which are oriented around a pre-pyproject.toml world and seem to require a separate source-of-truth for dependencies. Among tools that do respect pyproject.toml, poetry and uv are the main contenders that I'm aware of. Having used both, I am willing to bet on uv winning over poetry. uv may be the newest, but it's had the most advantage of seeing what works and doesn't works in other language ecosystems, and from what I've seen so far it makes the best decisions.

[michaelsilver]

I see, this makes sense. I think the Python ecosystem really screwed itself with the recent move to pyproject.toml, as previously with setup.py there was a straightforward way to manage a requirements.txt file alongside.

Let’s move forward with uv then. To ease the transition, can you write in a README how someone can setup their local environment, compile and contribute to this project? I think the appropriate background to expect from a reader is someone who’s used virtual environments but has no familiarity with uv. I want to avoid getting tripped up or having to learn a new tool from scratch; a guide like this will definitely pay off.

[ellipsis-dev]

👍 Looks good to me! Incremental review on b5b972b in 2 seconds

More details

• Looked at 67 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. python/README.md:43

• Draft comment:
  Typo: 'Liunux' should be 'Linux'.

To install it on Mac or Linux, run:

• Reason this comment was not posted:
  Confidence changes required: 10%
  The README.md file contains a typo in the word 'Linux'.

Workflow ID: wflow_5kxxH2Um23kxDybl

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[paulgb]

Sounds good, I've fleshed out the readme a bit more to include installing uv and give some basics on using it (e.g. that it doesn't need to be used with virtualenv).

I think the Python ecosystem really screwed itself with the recent move to pyproject.toml, as previously with setup.py there was a straightforward way to manage a requirements.txt file alongside.

I think pyproject.toml is a change in the right direction. The prior setup.py/distutils approach made sense at the time when it pre-dated any sort of package management or virtual environments, but now that we have things like pip and virtual environments, it's a pretty archaic way of doing things. In addition to not supporting lockfiles, having the metadata format for a package defined programmatically means that you can't really support things like uv add which need to modify the metadata.

[michaelsilver]

Everything looks great, thanks for the super helpful README!