feat: --package-installer option #708

amol- · 2025-09-18T17:46:08Z

Intent

Allows users to pass a --package-installer=pip|uv option to force a specific package manager.
By default it's up to the server (and it's backward compatible with server that didn't accept uv)

Closes #707

Type of Change

Bug Fix
New Feature
Breaking Change

Approach

The package_manager setting is now propagated in the Environment object and can be used by both deploy and write manifest processes.

Automated Tests

Added tests for the 3 cases

=uv
=pip
omitted

Directions for Reviewers

If in doubt see https://docs.posit.co/connect/user/manifest/#python

Checklist

I have updated CHANGELOG.md to cover notable changes.
I have updated all related GitHub issues to reflect their current state.

github-actions · 2025-09-18T17:46:41Z

PR Preview Action v1.6.3
🚀 View preview at https://posit-dev.github.io/rsconnect-python/pr-preview/pr-708/
Built to branch `gh-pages` at 2025-12-11 15:25 UTC. Preview will be ready when the GitHub Pages deployment is complete.

github-actions · 2025-09-18T17:47:54Z

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
5107	3869	76%	0%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
rsconnect/bundle.py	80%	🟢
rsconnect/environment.py	87%	🟢
rsconnect/main.py	67%	🟢
TOTAL	78%	🟢

updated for commit: 7cf1ee6 by action🐍

nealrichardson · 2025-09-24T11:56:08Z

I apologize in advance for the driveby comment about naming, but: given that "Package Manager" is one of Posit's products, I worry that calling this argument --package-manager is ambiguous or confusing. My instinct, without reading the docs, would be that I would provide a URL to the repository (Posit Package Manager) where I want packages to be downloaded from, not that this is how I would specify whether to use pip or uv pip.

I don't have an alternative to suggest, just wanted to flag this. Maybe this is fine?

tdstein · 2025-09-24T13:18:25Z

I apologize in advance for the driveby comment about naming, but: given that "Package Manager" is one of Posit's products, I worry that calling this argument --package-manager is ambiguous or confusing. My instinct, without reading the docs, would be that I would provide a URL to the repository (Posit Package Manager) where I want packages to be downloaded from, not that this is how I would specify whether to use pip or uv pip.

I don't have an alternative to suggest, just wanted to flag this. Maybe this is fine?

I think "--package-installer" could work since this is strictly about installation and not other package management operations.

PyPI references "package installer":
https://pypi.org/project/pip/

pip is the package installer for Python.

The Python Packaging guide also generally qualifies "installation"
https://packaging.python.org/en/latest/guides/tool-recommendations/#installing-packages

pip is the standard tool to install packages from PyPI.

The UV documentation is less precise:
https://docs.astral.sh/uv/getting-started/features/#the-pip-interface

uv pip install: Install packages into the current environment.

amol- · 2025-09-24T13:58:00Z

I apologize in advance for the driveby comment about naming, but: given that "Package Manager" is one of Posit's products, I worry that calling this argument --package-manager is ambiguous or confusing. My instinct, without reading the docs, would be that I would provide a URL to the repository (Posit Package Manager) where I want packages to be downloaded from, not that this is how I would specify whether to use pip or uv pip.

in Python specific terms that would probably be the "Package Index": https://pip.pypa.io/en/latest/cli/pip_search/#cmdoption-i

I guess that anyone using the PPM would be used to already specify that as the "index" both in requirements.txt and command line, so I feel it wouldn't confuse them much.
If we were in the R ecosystem I think your concern would have been very concrete, but in Python there is consistency from all tools to use the word Index and thus people are generally already exposed to it.

amol- · 2025-09-24T14:28:28Z

I think "--package-installer" could work since this is strictly about installation and not other package management operations.

I don't have a strong opinion, on this side there is a lot of confusion 🤷🏻

UV docs -> An extremely fast Python package and project manager, written in Rust.
Pip docs -> pip is the package installer for Python
poetry docs -> Poetry is a tool for dependency management and packaging in Python
conda docs -> Conda is a powerful command line tool for package and environment management
pipx docs -> pix is a tool ... focused on installing and managing Python packages

jonkeane · 2025-10-03T12:33:18Z

What about having --use-pip and the mutually exclusive --use-uv? I know it's a little funky to have two options that are mutually exclusive, but in this case it gets us out of this bind. I don't think we need to worry too much that there will be large numbers of these so having many many options won't happen. And I also suspect that folks will have pip or uv closer at hand / as rigid designators rather than the specific class of things those things are. (eg: I'm pretty sure I hear more people say things like "Do you use pip or uv?" rather than hearing "Which package [manager|installer] do you use?").

I share Neal's concern that the unfortunate collision with the Posit product is likely to lead to confusion. If we had to we could recover from that being super explicit if someone puts something other than uv or pip in there, but this is an area that is already mildly confusing general, I would like to not add a log on that fire if we don't have to.

amol- · 2025-12-09T10:41:56Z

@jonkeane this has been open for a while. I'm not fond of --use-pip because it's specific and we might end up growing further possible values in the future. But I'm happy to change the option to be --package-installer=pip|uv to avoid the clash with the posit package manager name. If that's ok I'll rebase the PR and get it out.

jonkeane · 2025-12-09T16:07:02Z

@jonkeane this has been open for a while. I'm not fond of --use-pip because it's specific and we might end up growing further possible values in the future. But I'm happy to change the option to be --package-installer=pip|uv to avoid the clash with the posit package manager name. If that's ok I'll rebase the PR and get it out.

Sure. I still truly believe that my original suggestion (--use-pip and --use-uv) is much more likely to be something the resonates with our users, but if the way to move this forward is to do --package-installer=pip|uv, that's fine.

tdstein

I think this looks good overall. The various possible configuration states is a bit confusing to me, but that may be unavoidable due to the server requirements.

I haven't run this code yet, so please let me know if you'd like me to sanity check that it works as expected.

tdstein · 2025-12-12T15:09:57Z

rsconnect/environment.py

-            self._data._replace(**{name: value})
+            self._data = self._data._replace(**{name: value})


😱 This was a bug?

yep... somehow we never faced it, but the data was indeed never updated

tdstein · 2025-12-12T15:11:57Z

rsconnect/environment.py

+            # Override the package manager name recorded by inspector
+            environment.package_manager = package_manager  # type: ignore[attr-defined]
+            # Derive allow_uv from selection
+            environment.package_manager_allow_uv = True if package_manager == "uv" else False


Trying to confirm my understanding... Is package_manager_allow_uv the same as "set the package manager to uv"?

python.package_manager.allow_uv in the manifest means: "Allow use of uv, if the server is configured to use it as the default package manager". When allow_uv=True if you configured python.package_manager.name=pip you allow the server to override your preference for "pip" if the server is configured to prefer "uv".

tdstein · 2025-12-12T15:13:58Z

rsconnect/environment.py

        python: typing.Optional[str] = None,
        override_python_version: typing.Optional[str] = None,
        app_file: typing.Optional[str] = None,
+        package_manager: typing.Optional[str] = None,


Would a Literal be better here? It looks like click is enforcing that the value is uv or pip at the command line. So, internally we could just defer to the type system to make sure we aren't passing around other values.

tdstein · 2025-12-12T15:15:04Z

rsconnect/environment.py

+            if package_manager not in ("pip", "uv"):
+                raise RSConnectException("Unsupported package manager: %s" % package_manager)


Changing package_manager to a Literal['uv', 'pip'] might remove the need for this check.

Fair, I retained the pattern the code has of checking values at runtime,
I'll switch to a validated value. But in this case I'd consider StrEnum a much better choice as it's a domain specific value, it benefits from being reusable and it's runtime safe too.

tdstein · 2025-12-12T15:17:02Z

rsconnect/main.py

    help='Force generating "requirements.txt", even if it already exists.',
 )
+@click.option(
+    "--package-installer",


I think we discussed this elsewhere, but having "package installer" here and then "package manager" in the source code is a little confusing.

package_manager is the actual name it has in the manifest.json, so the code related to generating the manifest uses that name. I agree that this is very confusing, but I feel it's even more surprising if you assign one value to the environment but then it writes a different one in the manifest.

tdstein · 2025-12-12T15:18:45Z

tests/test_bundle.py

+        ) as bundle, tarfile.open(mode="r:gz", fileobj=bundle) as tar:
+            manifest = json.loads(tar.extractfile("manifest.json").read().decode("utf-8"))
+            assert manifest["python"]["package_manager"]["name"] == "uv"
+            assert manifest["python"]["package_manager"]["allow_uv"] is True


Again, I'm not sure why "allow_uv" is required here alongside "name" = "uv". It seems like the server should respond with an error if ["python"]["package_manager"]["name"] == "uv" but it doesn't support uv.

It is not required as far as I remember, you are correct. I just preferred to avoid any gray areas and set both values to "use uv" and be consistent.

amol- changed the title ~~first import~~ feat: --package-manager option Sep 18, 2025

amol- marked this pull request as ready for review September 24, 2025 15:05

amol- and others added 3 commits December 11, 2025 16:09

first import

0751286

Add CHANGELOG

b681386

rename package_manager to package_installer

d93dc53

amol- force-pushed the set-required-package-manager branch from 2748dae to d93dc53 Compare December 11, 2025 15:19

amol- added 2 commits December 11, 2025 16:23

lint

6ea9f58

merge strings in help message

7cf1ee6

amol- changed the title ~~feat: --package-manager option~~ feat: --package-installer option Dec 11, 2025

tdstein self-requested a review December 12, 2025 15:04

tdstein approved these changes Dec 12, 2025

View reviewed changes

		self._data._replace(**{name: value})
		self._data = self._data._replace(**{name: value})

		if package_manager not in ("pip", "uv"):
		raise RSConnectException("Unsupported package manager: %s" % package_manager)

feat: --package-installer option #708

Are you sure you want to change the base?

feat: --package-installer option #708

Uh oh!

Conversation

amol- commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Intent

Type of Change

Approach

Automated Tests

Directions for Reviewers

Checklist

Uh oh!

github-actions bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Built to branch gh-pages at 2025-12-11 15:25 UTC. Preview will be ready when the GitHub Pages deployment is complete.

Uh oh!

github-actions bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

☂️ Python Coverage

Overall Coverage

New Files

Modified Files

Uh oh!

nealrichardson commented Sep 24, 2025

Uh oh!

tdstein commented Sep 24, 2025

Uh oh!

amol- commented Sep 24, 2025

Uh oh!

amol- commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonkeane commented Oct 3, 2025

Uh oh!

amol- commented Dec 9, 2025

Uh oh!

jonkeane commented Dec 9, 2025

Uh oh!

tdstein left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

amol- commented Sep 18, 2025 •

edited

Loading

github-actions bot commented Sep 18, 2025 •

edited

Loading

Built to branch `gh-pages` at 2025-12-11 15:25 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

github-actions bot commented Sep 18, 2025 •

edited

Loading

amol- commented Sep 24, 2025 •

edited

Loading