feat: basic support for uv.lock #750
Conversation
|
☂️ Python Coverage
Overall Coverage
New FilesNo new covered files... Modified Files
|
rsconnect/main.py
Outdated
| "Path to requirements file to record in the manifest instead of detecting the environment. " | ||
| "Must be inside the notebook directory. Use 'none' to capture via pip freeze." | ||
| ), | ||
| help=("Path to requirements file listing the project dependencies. " "Must be inside the notebook directory."), |
There was a problem hiding this comment.
Those help message changes are unrelated to this PR, but I have been trying to improve them based on #748 comments
There was a problem hiding this comment.
Could we add details something like: "this might be a file like the standard requirements.txt, but any file that lists dependencies is accepted. For example a requirements.txt.lock file could also be used which will recreate the environment with exactly the versions listed in that lock file."
My concern on #748 is that we call this requirements-file and I believe most of our users will interpret this to mean that only a requirements.txt can be submitted. And they will never think that they could also submit a lock file to this. I understand that in the Python world these files are effectively in a subset/superset relationship and that both are "requirements file"s in our / Python parlance. But I don't think that is true of our data scientist users, and want to make sure we make it clear to them that the requirements-file option can indeed accept a lock file.
There was a problem hiding this comment.
Oh I see what you mean.
This is confusing because the glossary is a bit fuzzy in this context.
For example if you use pip-tools the requirements.txt is the lockfile and the requirements.in is the dependencies file.
requirements.txt.lock isn't a convention in the python ecosystem, it's specific to Connect as the requirements.txt was already used with a different meaning.
Would it make sense to phrase it as
Path to requirements file listing the project dependencies.
Any file compatible with requirements.txt format or uv.lock is accepted,
a requirements.txt.lock retrieved with "rsconnect content get-lockfile" is also supported.
Must be inside the project directory.
?
|
Wouldn't the same approach work (more or less) for pyproject.toml? pylock.toml? I love that we're doing uv.lock, but seems reasonable to follow with the others, right? (See also #327.) |
Yes, I wanted to try this approach specifically because it's flexible. But before jumping on the bandwagon and saying that it can work for everything I wanted to put out one format (supported only when explicitly requested by the user and not automatically) to check what limitations users are going to face out in the wild. If this approach proves as viable as I expect, with only a minority of corner cases not supported, I think we can expand it to any other format. |
| "Path to requirements file listing the project dependencies. " | ||
| "Any file compatible with requirements.txt format or uv.lock is accepted, " | ||
| "a requirements.txt.lock retrieved with 'rsconnect content get-lockfile' is also supported. " | ||
| "Must be inside the project directory." |
There was a problem hiding this comment.
so just to be clear this accepts any of these:
- uv.lock
- requirements.txt
- requirements.txt.lock
Can we state this more simply? Does it matter where the requirements.txt.lock came from?
There was a problem hiding this comment.
requirements.txt.lock isn't really a thing, it can only come from connect itself when downloaded with get-lockfile .
From python point of view is just a perfectly normal requirements.txt with a different name, but the concerns voiced here #750 (comment) seemed to be that some users might now immediately understand they can send back a connect requirements.txt.lock unless explicitly documented
|
|
||
| requirements = filter_pip_freeze_output(exported) | ||
| requirements = ( | ||
| "# requirements.txt.lock generated from uv.lock by rsconnect-python on " |
There was a problem hiding this comment.
I am providing a uv.lock file and this message is not what I am seeing. Instead I see from requirements.txt.lock
There was a problem hiding this comment.
Uhm, Can you elaborate?
This is a comment that is prefixed to the requirements file uploaded to connect so that when the bundle is accessed for debugging purposes there is a hint that the requirements were not written by a user but were generated from a uv.lock
There was a problem hiding this comment.
My bad, actually referring to this in the logs when deploying with uv.lock attached:
2025/12/19 18:30:53.191895006 Generating lockfile python/requirements.txt.lock from requirements.txt.lock
Intent
Allow user to specify
uv.lockas the requirement file when deploying content to connect.This intentionally avoids automatically detecting a
uv.lockand preferring it as it would be an existing behavior change.We can definitely implement such a behavior in the future as the implemented approach proves to be well received by users.
closes #749
Type of Change
Approach
When
--requirements-filereceivesuv.lockas its value,we parse the uv lockfile and generate a
requirements.txt.lockfrom itPaired with our existing support for
.python-versionthis allows users to deploy content to connect on an environment that mimics their local uv environment.Automated Tests
A test that verifies
inspect_environmentcorrectly handlesuv.lockhas been added (test_uv_lock_export)Directions for Reviewers
On an existing project having a
requirements.txt(but not a uv.lock) you can doThat will generate a
uv.lockfile that is based on yourrequirements.txt,now you can deploy using it
you should get the same exact environment you had with your previous
requirements.txtChecklist
rsconnect-python-tests-at-nightworkflow in Connect against this feature branch.