Auto-update requirements.txt after Python package install/uninstall#14605
Auto-update requirements.txt after Python package install/uninstall#14605bricestacey wants to merge 9 commits into
Conversation
|
E2E Tests 🚀 |
PETE's assessment 🧪Verdict: 🟢 Adequate -- The PR adds unit tests at all three layers (pure editor, sync orchestration, and both pip/uv manager integrations) that directly exercise the new install-appends / uninstall-removes / setting-gated / project-untouched behavior. What changed
Tests in this PR
Existing coverage
Suggested additionsNone. Coverage maps cleanly to the changed behavior: editor edge cases (continuation/hash/PEP503/no-op), sync's confirm-then-write and failure-swallowing, and both managers' install-appends / uninstall-removes / setting-disabled / project-workflow-untouched paths. PETE (Positron Extreme Test Experiment) - LLM-based test-coverage advisor, in pilot. Triggers on PR open and on |
|
This screenshot demonstrates that after installing 
|
| return content; | ||
| } | ||
| const needsNewline = content.length > 0 && !content.endsWith('\n'); | ||
| return `${content}${needsNewline ? '\n' : ''}${name}\n`; |
There was a problem hiding this comment.
This write-back is great, but I think I'm just a little uncomfortable with doing it by default without user opt-in. I think we could solve this a few different ways:
- default the setting to
false - have a confirmation prompt or at least an info notification the first time we do this
- show a diff view that they can accept (we do this with the "import vs code settings" gesture for example)
- add comments where Positron changed the file, like
requests # added by Positronor# requests removed by Positron
There was a problem hiding this comment.
My vote would be to:
- Default false
- First time a workspace has a requirements.txt show a notification
"Positron can keep requirements.txt in sync with installed packages. [Enable] [Not now]". - If enabled
add comments where Positron changed the file, like requests # added by Positron or # requests removed by Positron
There was a problem hiding this comment.
Should we punt this issue to the next release then?
Alternatively, we could default to false so it's opt in and then follow-up with the improvements next release.
There was a problem hiding this comment.
I think I'm cool with defaulting to false for 07 and doing the rest as followups.
Make requirements.txt auto-update opt-in rather than on by default, so it never modifies a user's requirements.txt without them enabling it. See #14343
Integrates #14627 (python.packageManager.useRequirementsFile opt-out) and #14608. Resolved conflicts in the pip/uv managers and uv test: kept both the new useRequirementsFile gate in _getWorkspaceRequirementsPath and the requirements.txt writeback. Because writeback is gated on _getWorkspaceRequirementsPath() (which now returns undefined when useRequirementsFile is disabled), auto-update is skipped whenever requirements.txt is not the source of truth, even if packages.python.autoUpdateRequirements is enabled. Added a pip test pinning this interaction. Pre-commit hook bypassed: it flagged extensions/copilot/*positronAssistant* files that are byte-identical to origin/main (unmodified upstream content swept in by the merge), not part of this change.
Relocate the requirements.txt source-of-truth opt-out from the positron-python extension (python.packageManager.useRequirementsFile, added in #14627) to Positron core as packages.python.useRequirementsFile, so it sits in the same namespace as packages.python.autoUpdateRequirements and appears under Features > Packages. The extension reads the core setting via the same configuration API. See #14343
|
After chatting with Brice, we're going to wait on this updating feature until 2026.08 (after Brice is back from OOO). One could argue it isn't too terrible what we let people do here; if you add a package via pip, pip itself won't update the I also vote for Cindy's suggestion in #14605 (comment). |
4 participants
Fixes #14343
Summary
After #14550 made a workspace-root
requirements.txtthe source of truth that pip/uv package operations resolve against (via-r <file>on the command line), the file itself was never written. Installing a package left it undeclared, so the environment drifted from what the project declares, and uninstalling a declared package didn't stick -- the next operation's-r requirements.txtreinstalled it.This PR keeps the file's declared set in sync after explicit package operations, mirroring R's
packages.r.renvAutoSnapshot:\-continuations and--hashlines).-rresolve already governs versions).The sync only runs when a workspace-root
requirements.txtalready exists (it is never created), acts only on the top-level requested package (never the transitive closure, unlikepip freeze), and is confirmed against the kernel's installed set before editing. It is decoupled from the operation: a write failure warns but never fails the install/uninstall. The uv project workflow (uv add/uv sync) is untouched since it already keepspyproject.tomlin sync; only theuv pipenvironment branch syncs.Gated by a new setting
packages.python.autoUpdateRequirements(boolean, defaulttrue).Release Notes
New Features
requirements.txtin sync, controlled by the newpackages.python.autoUpdateRequirementssetting (packages pane: python package operations should update the project's declarative dependency files #14343)Bug Fixes
Validation Steps
@:packages-pane
requirements.txtcontainingrequests==2.28.2, using a Python environment:pandas->requirements.txtgains a barepandasline; therequestspin is unchanged.requests-> Uninstall -> therequests==2.28.2line is removed.requirements.txtis unchanged.packages.python.autoUpdateRequirementstofalse, install another package -> the file is not modified.requirements.txtread-only, install a package -> a warning appears and the package still installs.