Skip to content

refactor: use uv and poe for everything #594

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

theagenticguy
Copy link
Collaborator

Description

Another pass at refactoring to use uv and also poe for task runners.

Why?

  1. you get uv.lock
  2. uv sync --all-groups, instantly get venv, python version, etc.
  3. uv run * commands automatically use the correct venv, no more problems with "which venv is activated"
  4. uv run poe * tasks automatically use uv and .venv for linting, testing, etc.

Also this PR simplifies the all optional package group so you don't have to worry about drifting version pins.
It also removes unused sphinx libs.

Related Issues

Documentation PR

Type of Change

Other (please describe): refactor the python build systems

Testing

How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli

  • I ran hatch run prepare

Checklist

  • I have read the CONTRIBUTING document
  • I have added any necessary tests that prove my fix is effective or my feature works
  • I have updated the documentation accordingly
  • I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
  • My changes generate no new warnings
  • Any dependent changes have been merged and published

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@theagenticguy theagenticguy marked this pull request as ready for review August 6, 2025 22:30
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of it for development, though I'm reluctant to use it as part of CI builds - we've noticed dependency problems that customers would encounter that we wouldn't have caught had we had a lock file.

At a minimum I think we'd want a CI build that doesn't use the lock file to ensure that we're actively catching dependency problems

@@ -118,127 +78,25 @@ all = [
"pytest-cov>=4.1.0,<5.0.0",
"pytest-xdist>=3.0.0,<4.0.0",
"ruff>=0.4.4,<0.5.0",
"poethepoet>=0.36.0,<0.37.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this compare to hatch's task running? AFAICT hatch can also run uv (https://hatch.pypa.io/dev/how-to/environment/select-installer/) so I'm curious as to the benefit of hatch vs poethepoet?

"starlette>=0.46.2,<1.0.0",
]
[tool.hatch.metadata]
allow-direct-references = true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this recommended for public packages? I see these docs which references the direct dependencies section which has:

Public index servers SHOULD NOT allow the use of direct references in uploaded distributions. Direct references are intended as a tool for software integrators rather than publishers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants