Migrate Python CLI template to uv

[jonavellecuerdo]

Purpose and background context

Migrate Python CLI template to uv

How can a reviewer manually see the effects of these changes?

The uv-based GitHub CI workflow has been tested in MITLibraries/timdex-embeddings#33

Includes new or updated dependencies?

YES

Changes expectations for external applications?

NO

What are the relevant tickets?

• https://mitlibraries.atlassian.net/browse/IN-1541
• https://mitlibraries.atlassian.net/browse/IN-1425

Code review

• Code review best practices are documented here and you are encouraged to have a constructive dialogue with your reviewers about their preferences and expectations.

[jonavellecuerdo]

Question for @ehanson8 and @ghukill : Should we exclude the uv.lock file similar to how we excluded the Pipfile.lock so as to avoid pinning dependencies for the template?

[coveralls]

Pull Request Test Coverage Report for Build 21186643805

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 17270497594:	0.0%
Covered Lines:	35
Relevant Lines:	35

---

💛 - Coveralls

[ehanson8]

Question for @ehanson8 and @ghukill : Should we exclude the uv.lock file similar to how we excluded the Pipfile.lock so as to avoid pinning dependencies for the template?

We don't seem to be excluding Pipfile.lock here, was that a recent decision?

[ehanson8]

Looking good but a few questions and comments

[ghukill]

Question for @ehanson8 and @ghukill : Should we exclude the uv.lock file similar to how we excluded the Pipfile.lock so as to avoid pinning dependencies for the template?

I would propose that we keep the uv.lock file. My understanding has always been that version controlling the lock files is good practice. That way, without a dependency update we know the Docker CI build will be identical. A little unsure why we were formerly excluding the Pipfile.lock files.

Looking at this commit @jonavellecuerdo, I'd propose re-adding it as a commit.

[ghukill]

Overall, looking great. Did request a couple of small changes, mostly things pointed out by @ehanson8.

I'd also like to propose an update to the README about running the CLI.

Under the section ## Development I'd propose updating this:

- To run the app: `uv run my-app --help` (Note the hyphen `-` vs underscore `_` that matches the `project.scripts` in `pyproject.toml`)

To the following, which shows two options:

- To run the app:
  - `my-app`
    - utilizes `uv` built entrypoint (see `project.scripts` in `pyproject.toml`)
    - does not support loading a `.env` file
  - `uv run --env-file .env my-app`
    - more verbose, but supports loading with a `.env` file

Thoughts?

[jonavellecuerdo]

Thank you both for your reviews, and especially @ehanson8 for catching references to my-app vs. python-cli-template! 😅 The latest commit addresses all your comments and suggestions!

[ghukill]

Left a comment about the Makefile and how to run the app. Most of the details in that comment itself.

[ghukill]

This is going to be complicated to discuss I fear in comments, but will try. Happy to realtime chat on this if helpful.

If this is related to the README update for how to run the app, my proposal was just my-app. This would work because my-app is built by uv as an entrypoint script here in the pyproject.toml. It would work without this Makefie command.

If possible, I'm feeling like we might benefit from leaning into those uv entrypoint scripts where possible. You can see an example of that in the timdex-embeddings CLI here where the Dockerfile is calling that uv entrypoint script directly. Nothing else.

[ghukill]

See another comment in the Makefile, where this could be just my-app.