To run Python code you need to ... 1. Choose the appropriate/best language version 2. Find/install an interpreter to meet that language version need ([[#`py install`]]) 3. Create a virtual environment that uses the selected interpreter ([[#`py venv`]]) 4. Install the code's dependencies ([[#`py ready`]]) 5. Run the code ([[#`py run`]]) # Goals - [ ] Easiest way to [[#`py launch` (or `py exec`)|launch an interpreter]] - [x] Select the newest version - [x] Specify the version - [ ] Support the major OSs - [x] Linux - [x] macOS - [ ] [[#Windows support]] - [ ] Registry - [ ] Microsoft Store - [x] From a virtual environment - [ ] Install an interpreter (requires [[Prebuilt binaries|Relocatable builds]]) - [ ] [[Virtual environment location]] - [ ] [Inline script metadata](https://packaging.python.org/en/latest/specifications/inline-script-metadata/) for `requires-python` only? - [ ] Easiest way to [[#`py list`|list interpreters]] - [ ] Fancy/human-readable - [ ] JSONL - [ ] Easiest way to [[#`py run`|run code]] 🏃 - [ ] [Inline script metadata](https://packaging.python.org/en/latest/specifications/inline-script-metadata/) - [ ] [[requires-python spec]] - [ ] `.py` files - [ ] Path - [ ] URL - [ ] Directories via `__main__.py`? - [ ] Zip files via `__main__.py`? - [ ] `pylock.toml` (takes care of interpreter selection and virtual environment creation, even if you do specify config details) - [ ] Scripts next to `pylock.toml`? - [ ] Directories w/ `__main__.py`? - [ ] Modules (`-m`) based on cwd? - [ ] `bin/` based on cwd? - [ ] Zip file? - [ ] `pyproject.toml` (takes care of interpreter selection and virtual environment creation, even if you do specify config details) - [ ] Write out lock file? - [ ] Scripts? - [ ] Directories w/ `__main__.py`? - [ ] Modules (`-m`) based on cwd? - [ ] Zip file? - [ ] `bin/` based on cwd? - [ ] Install Python on demand (requires [[Prebuilt binaries|Relocatable builds]]) - [ ] `py x` shorthand (like from `chmod`, plus nod to pipx)? - [ ] `venv` + `ready` for more manual control while keeping installation of packages simple (requires way to launch interpreter only) - [ ] Easiest way to [[#`py tool`|run tools]] 🧰 - [ ] Install - [ ] Run (`py x`?) # Ideas ## Automatic virtual environment management The goal is to make virtual environments an implementation detail to help prevent users from messing up their install and to simplify their workflows. There are two situations to consider: _ephemeral_ environments (like for inline script metadata), and _long-lasting_ environments (e.g. `.venv/` in a project). Probably need to make sure that if they manage to install something into an ephemeral virtual environment it's considered different than when it was first created. Simplest thing would be to create a single-use lock file for the environment and verify that everything matches. The next possibility that's even more robust is to keep projects unpacked somewhere, have them be read-only and recreate the virtual environments from scratch every time via filesystem links. Determining which ephemeral virtual environment to use could be done by hashing the inputs used to do the install. Ephemeral virtual environments should be occasionally cleaned up. Maybe every 30 days or past the same day of the month the following month? It could be done in a background thread for all ephemeral virtual environments. There should also be a way to forcibly recreate the virtual environment to make sure to use the newest project versions. ## Subcommands [Proposal for user-contributed subcommands](https://github.com/brettcannon/python-launcher/discussions/222) - Make each command a feature of the crate to control what commands are available? - Complex commands should decompose to other commands ### `py exec` [[launch]] ### `py list` [[list]] ### `py install` [[install]] ### `py venv` [[venv]] ### `py ready` [[sync]] ### `py run` [[run]] ### `py tool` [[tool]] ### `py completions` [[completions]] ## Windows support - [Virtual environments](https://github.com/brettcannon/python-launcher/issues/57) - [`PATH`](https://github.com/brettcannon/python-launcher/issues/14) - [Registry](https://github.com/brettcannon/python-launcher/issues/15) - [Microsoft Store](https://github.com/brettcannon/python-launcher/issues/16) # Python rewrite Since the Launcher _probably_ has a bottleneck on I/O from interacting with the file system, having it implemented in Python instead of Rust may not actually be a performance penalty. Distribution should also _generally_ not be impacted. The Rust version is distributed via: 1. crates.io 2. GitHub Releases as a single binary and manpage 3. Package managers as a Rust app A Python version could be distributed via: 1. PyPI 2. GitHub Releases as installers created by Briefcase 3. Package managers as a Python app So performance will be the deciding factor. A 1:1 comparison that can be done cheaply via `py --version` as that just requires support for: - `VIRTUAL_ENV` - `.venv` - `PATH` https://snarky.ca/should-i-rewrite-the-python-launcher-for-unix-in-python/