You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 26c78f6
Browse filesBrowse the repository at this point in the historyBrowse files
Register PEP 723 scripts as exact projects (PEP 723 PR 10/16) (#1744)
> Part of #1602 (PEP 723 inline script env support). Design doc: #1601.
### Roadmap context
This is **PR 10 of 16** in the PEP 723 inline-script roadmap. PRs 7-9
persist, discover, validate, and route per-script environments; this PR
gives each configured script an exact project identity that survives
restart and can be consumed by per-file integrations.
| Phase 3 / integration | PR | Status |
|---|---|---|
| | PR 7: per-script persistence | merged (#1697) |
| | PR 8: activation-time discovery | merged (#1722) |
| | PR 9: automatic per-script routing | merged (#1729) |
| | **PR 10: exact script project registration** | **this PR** |
| | PRs 11-12: CodeLens and bulk setup UX | follow-up |
| | PR 17: Pylance per-file Python path |
[microsoft/pyrx#9265](microsoft/pyrx#9265) |
| | PR 19: Python extension per-file lookup |
[microsoft/vscode-python#26129](microsoft/vscode-python#26129)
|
### Why this PR
PR 9 can route a saved script to a validated inline environment, but the
project manager still identifies the script through its containing
workspace project. That prevents the per-file identity from surviving
restart consistently and leaves downstream configuration and
environment-change consumers without an exact script scope.
The registration also needs an ownership boundary: clearing inline
environments must remove entries created by the extension without
deleting user-authored project settings.
### What this PR does
- Registers an exact `pythonProjects` entry before binding an inline
environment.
- Stores the normal environment and package manager as the script's
fallback rather than replacing them with the inline manager.
- Marks extension-managed entries as either:
- `created`: remove the entry during inline cleanup;
- `adopted`: remove only the marker and preserve the user's entry.
- Ignores the managed fallback entry while a validated inline
association is routeable.
- Uses that entry normally when the feature is disabled or the
association becomes stale.
- Rolls back a newly prepared registration if inline association binding
fails.
- Supports single and batch script selection.
- Converts a managed entry into an ordinary user-owned entry when the
user explicitly selects a non-inline manager.
- Coordinates explicit managed selections with the dedicated clear-cache
operation.
- Resolves and updates same-named scripts correctly in multi-root
workspaces.
### Registration and cleanup semantics
| Condition | Behavior |
|---|---|
| No exact project entry exists | Create a marked entry containing the
ordinary fallback managers |
| An exact user entry exists | Temporarily mark it without changing its
manager choices |
| Inline binding fails | Roll back the marker/created entry and any
newly added in-memory project |
| Validated association exists | Route through the inline manager |
| Association is stale or unavailable | Use the stored fallback manager
|
| User selects a non-inline manager | Update the owning setting and
remove the managed marker |
| Clear Script Environment Cache | Remove created entries; restore
adopted entries |
| Two roots contain the same relative script path | Match using the
`workspace` discriminator |
### Performance and safety
- No workspace scan is introduced.
- Configuration writes occur only during explicit persisted selection,
rollback, manager changes, or dedicated cache cleanup.
- Serialization is limited to managed inline-script project mutations;
unrelated environment routing and refresh operations are not queued.
- User-owned project settings are never deleted by inline cleanup.
### User impact
The feature remains behind `python-envs.inlineScripts.enabled`. Existing
users and projects without a managed inline-script entry retain their
current manager-selection behavior. After setup, a script has a stable
exact project scope across reloads; when inline routing is unavailable,
its previous project/workspace environment remains the fallback.
### Tests
- `npm run compile-tests`
- `npm run compile`
- `npm run lint`
- Focused command, environment-manager, and settings tests: **92
passing**
- The full unit suite was also run. Six unchanged timing-sensitive
inline-manager tests failed only under full-suite load and passed
together in an isolated rerun.
### Scope and follow-up
This PR does not add the setup CodeLens, bulk setup command, TTL
eviction, or public feature enablement. Those remain in PRs 11, 12, and
14. Per-file language-service and debugger integration are handled by
the companion cross-repository PRs above.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
0 commit comments