Leverage `uv` #1257

jakob-keller · 2025-01-07T08:09:16Z

Description of Change

Leverage uv for local development environment and CI/CD pipeline.

Assumptions

Replace this text with any assumptions made (if any)

Checklist for All Submissions

Checklist when updating botocore and/or aiohttp versions

I have read and followed CONTRIBUTING.rst
I have updated test_patches.py where/if appropriate (also check if no changes necessary)
I have ensured that the awscli/boto3 versions match the updated botocore version

codecov · 2025-01-07T08:11:51Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.02%. Comparing base (7432338) to head (a3f8f66).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1257      +/-   ##
==========================================
- Coverage   88.05%   88.02%   -0.04%     
==========================================
  Files          67       67              
  Lines        5904     5904              
==========================================
- Hits         5199     5197       -2     
- Misses        705      707       +2

Flag	Coverage Δ
unittests	`88.02% <ø> (-0.04%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

pyproject.toml

thehesiod · 2025-01-07T19:54:45Z

pyproject.toml

+    "requests ~=2.32.3", # Used in test_version.py
+    "time-machine ~=2.15.0",
+    "tomli; python_version<'3.11'", # Used in test_version.py
+    "werkzeug ~=3.0.6", # Used in moto_server.py


this is a side-effect of moto, if moto changes werkzeug we need to change our impl as well. IOW this is not our choice

if it makes you feel better can import this from moto directly ;)

Sorry, if I'm mistaken, but I thought we had resolved that as part of #1246. We use werkzeug directly in unit tests and that specification guards us from regressions should moto drop that dependency. I agree that we might then subsequently also drop werkzeug, but that's a separate issue, IMO.

Exactly: https://github.com/aio-libs/aiobotocore/blob/7432338/tests/moto_server.py#L12C1-L12C16

no, see my reply: #1246 (comment)

if moto stops using that library, we NEED to update our code, and having the import fail is a feature letting us know something needs to be re-written to match moto

if we include that library we're going to have some weird side-effect behavior of moto moves away from using the library

It's a direct dependency right now: #1246 (comment). Pretending that it isn't wouldn't change the fact that it is, it'd only make it more confusing.

how is it confusing? This is just for aiobotocore developers, if you think the two people that ever maintain deps would get confused add a comment on the only import line saying we're not including the dep because we want the code to break if moto ever moves away from werkzerg

following rules for rules sake is fools errand, there will always be exceptions

webknjaz

My biggest concern is forcing yet another tool on contributors.

webknjaz · 2025-01-07T20:05:08Z

CONTRIBUTING.rst

@@ -13,31 +13,24 @@ First of all, clone the repository::

    $ git clone [email protected]:aio-libs/aiobotocore.git

-Create virtualenv with at least python3.8 (older versions are not supported).


I don't think it's a good idea to dictate contributing workflows in general. Less vendor locking is better.

That's a valid point and I strongly convinced our documentation may be improved upon. Since I'm not a technical writer nor an English native, I hesitate to take the initiative.

What I like about uv is that it works well out-of-the-box and makes many of the previously documented steps obsolete.

If there was a standard lock file format and tooling that supported it, we would be in a different place, but as of now, I believe uv offers the best overall experience and is a major step forward for this project.

If there is no consensus, we may well close this PR. No hard feelings: it was not a lot of effort to put this together.

I think that it's good for CI. I'm just concerned that telling people to install a tool that messes with their userspace by default is not to be taken lightly.
Personally, I tend to be cautious when it comes to such things. I'm comfortable with tox because I know it won't affect my env beyond the project dir, for example.
I've been playing with pipx/uvx recently, but really carefully.
I think that there would be a portion of contributors that would feel like we're sending them off to learn an entirely new tool and its implications. So if there's a way to improve this, it should be taken into account.
This was one of my problems w/ Poetry, by the way. To this day, I avoid interacting with projects that don't let me do my thing w/o touching it.
OTOH, it's probably fine where there's CI to validate changes — in such cases, I just edit the files, push the thing and hope to see some feedback from the interface that isn't as eager to interfere with how I get to use my computer.

What is your take on dev containers? Would that address your objections? I want to learn about those this year.

Honestly, all active contributors have already commented on this PR. Not sure if there is anyone else that feels strongly about these issue - or at all.

What is your take on dev containers? Would that address your objections? I want to learn about those this year.

I've been meaning to look deeper into these as well. I think, they might be a good interface to declare (and keep working through CI). They'd enable more contributors, especially those from the VS Code land or GitHub Codespaces.

I'm a NeoVim user (AstroNvim mostly) and I'd like to try them out too, I've heard there's integrations.

But I think the main benefit is that enabling more contributors to start seamlessly is not blocking anybody who wouldn't want to opt in.

Honestly, all active contributors have already commented on this PR. Not sure if there is anyone else that feels strongly about these issue - or at all.

Fair. Although, I'm mostly thinking of potential contributors, not the existing ones. The existing contributors are more likely to adapt and try out different things. But if for somebody the entry barrier is becoming higher, it might gate them and prevent them from trying.

CONTRIBUTING.rst

jakob-keller · 2025-01-07T22:43:46Z

My biggest concern is forcing yet another tool on contributors.

My sales pitch would be that in our context uv is primarily a direct replacement of pip-tools, but also (optionally) substitutes:

pyenv, installers from python.org, ... (to provision Python toolchain)
virtualenvwrapper, venv, ...? (for managing virtual environments)
pip (as package installer)
build (as build frontend in CI/CD)

For me personally, having worked mostly on poetry based projects, it's a single, well-known tool, that is trivial to adopt and improves developer experience by a lot. And it may be used in conjuncture with existing tools, if one prefers to take that route.

webknjaz · 2025-01-07T23:02:47Z

Well, let's try it out. I've outlined my concerns and I think that uv pip-compile would've been less intrusive. But I suppose it's okay to attempt doing this and revert if it doesn't work out.

jakob-keller · 2025-01-07T23:10:01Z

Well, let's try it out. I've outlined my concerns and I think that uv pip-compile would've been less intrusive. But I suppose it's okay to attempt doing this and revert if it doesn't work out.

I really, really appreciate your thoughtful reviews.

jakob-keller added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Jan 7, 2025

jakob-keller self-assigned this Jan 7, 2025

jakob-keller force-pushed the uv branch 4 times, most recently from ab02d7e to 762f9ba Compare January 7, 2025 08:29

jakob-keller marked this pull request as ready for review January 7, 2025 08:31

jakob-keller requested review from thehesiod and webknjaz January 7, 2025 08:31

jakob-keller mentioned this pull request Jan 7, 2025

Use best practice dependency management #1188

Open

thehesiod reviewed Jan 7, 2025

View reviewed changes

pyproject.toml Show resolved Hide resolved

thehesiod reviewed Jan 7, 2025

View reviewed changes

pyproject.toml Outdated Show resolved Hide resolved

thehesiod reviewed Jan 7, 2025

View reviewed changes

webknjaz reviewed Jan 7, 2025

View reviewed changes

jakob-keller force-pushed the uv branch from 762f9ba to 68f7db3 Compare January 7, 2025 22:52

leverage uv

a3f8f66

jakob-keller force-pushed the uv branch from 68f7db3 to a3f8f66 Compare January 8, 2025 07:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Leverage `uv` #1257

Leverage `uv` #1257

jakob-keller commented Jan 7, 2025

codecov bot commented Jan 7, 2025 •

edited

Loading

thehesiod Jan 7, 2025

thehesiod Jan 7, 2025

jakob-keller Jan 7, 2025

webknjaz Jan 7, 2025

thehesiod Jan 8, 2025

thehesiod Jan 8, 2025

thehesiod Jan 8, 2025

webknjaz Jan 8, 2025

thehesiod Jan 8, 2025 •

edited

Loading

thehesiod Jan 8, 2025

webknjaz left a comment

webknjaz Jan 7, 2025

jakob-keller Jan 7, 2025

jakob-keller Jan 7, 2025 •

edited

Loading

webknjaz Jan 7, 2025

jakob-keller Jan 7, 2025

jakob-keller Jan 7, 2025

webknjaz Jan 7, 2025

jakob-keller commented Jan 7, 2025

webknjaz commented Jan 7, 2025

jakob-keller commented Jan 7, 2025

		@@ -13,31 +13,24 @@ First of all, clone the repository::

		$ git clone [email protected]:aio-libs/aiobotocore.git

		Create virtualenv with at least python3.8 (older versions are not supported).

Leverage uv #1257

Are you sure you want to change the base?

Leverage uv #1257

Conversation

jakob-keller commented Jan 7, 2025

Description of Change

Assumptions

Checklist for All Submissions

Checklist when updating botocore and/or aiohttp versions

codecov bot commented Jan 7, 2025 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thehesiod Jan 8, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

webknjaz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakob-keller Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakob-keller commented Jan 7, 2025

webknjaz commented Jan 7, 2025

jakob-keller commented Jan 7, 2025

Leverage `uv` #1257

Leverage `uv` #1257

codecov bot commented Jan 7, 2025 •

edited

Loading

thehesiod Jan 8, 2025 •

edited

Loading

jakob-keller Jan 7, 2025 •

edited

Loading