posit-dev / posit-dev/positron
Reconsider installing ipykernel to global Python environments
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 4.3k
- Forks
- 184
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 206
Description
We originally addressed https://github.com/posit-dev/positron/issues/2005 by passing the --break-system-packages flag (it's not as bad as it sounds! Here was our reasoning).
The issue has since been addressed upstream in https://github.com/posit-dev/positron/commit/3f71b1ccbb9c3fb5e3750887b4c4a210f8a7b79a using IDE-shell integration to detect if a user tries to do pip install in a global environment, and suggest they instead create a new environment.
We should double-check how this interacts with our quickfix and decide whether to roll back our fix. IIUC it currently only detects pip installs in the shell, but we would want to apply the same flow when trying to install ipykernel into an interpreter upon startup.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the quickfix that installs ipykernel and the startup path that installs it into an interpreter. Compare their behavior with the linked upstream IDE-shell integration and the reasoning in commit c1408d52. Done means deciding whether the existing --break-system-packages handling should be rolled back and applying the same global-environment flow to startup installation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- jupyter, python, typescript
- Domain
- developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100