diff --git a/peps/pep-0832.rst b/peps/pep-0832.rst index 87eb64bfe6d..838786178b7 100644 --- a/peps/pep-0832.rst +++ b/peps/pep-0832.rst @@ -15,11 +15,12 @@ Post-History: `15-Apr-2026 `__ Abstract ======== -This PEP sets out to help make the discovery of a project's existing -environments easier. By providing a default location to look for a virtual +This PEP sets out to help make the discovery of a project's preferred virtual +environment easier. By providing a default location to look for a virtual environment as already supported by most tools as well as an easy way for -workflow tools to list any other environments (virtual or not), tools will have -a way to find any and all existing environments for a project. +workflow tools to point to a virtual environment placed somewhere other than +the default location, tools will have a way to find the project's preferred +virtual environment. Motivation @@ -29,28 +30,26 @@ Imagine you are on your Mac laptop and you double-click your desktop shortcut to launch Emacs (feel free to substitute "Mac" and "Emacs" with your preferred OS and editor, respectively). You open the directory for your project in Emacs. Now, how is Emacs (or any other tool for that matter) supposed to know where -the environments for your project are? There's no possible detection of an -activated virtual environment via the ``VIRTUAL_ENV`` environment variable -because you didn't launch it from a terminal. You potentially could scan all -subdirectories for a :file:`pyvenv.cfg` file to find a virtual environment, but -that assumes the virtual environments are kept locally with the project and -that there is only one of them, rather than several from which to choose. -As well, not all projects use virtual environments and may use a different -project isolation mechanism like conda environments. +the environments for your project are if they already exist? There's no +possible detection of an activated virtual environment via the ``VIRTUAL_ENV`` +environment variable because you didn't launch it from a terminal. You +potentially could scan all subdirectories for a :file:`pyvenv.cfg` file to find +a virtual environment, but that assumes the virtual environments are kept +locally with the project. What are tools like code editors, which need access to the environments being used to provide functionality like auto-complete, to do when there is currently -no standardized way to tell anyone where any environments are? Currently, -tools like editors have to hard-code a search algorithm for every tool that -they choose to support. As well, they can document any conventions they -support, but that assumes you or the tool you use to manage your environments -follow those conventions, which, being conventions, are not written down -anywhere. +no standardized way to tell anyone where the preferred virtual environment is? +Currently, tools like editors have to hard-code a search algorithm for every +tool that they choose to support. As well, the tool can document any +conventions they support, but that assumes you or the tool you use to manage +your virtual environments follow those conventions, which, being conventions, +are not written down anywhere as a standard. And this is not a hypothetical issue. The author of this PEP was the dev manager for Python support in VS Code for 7 years and saw firsthand the -user struggles and constant feature requests for finding one's environments for -a project. +struggling of users and constant feature requests for finding one's +environments for a project. This issue is also not restricted to code editors. Other tools have a need to access a project's environment to know what is installed. One example is @@ -59,11 +58,12 @@ appropriately gather type annotations for 3rd-party code in order to type check the user's code. The goal of this PEP is to provide a specification for tools which -create/manage environments a way to tell other tools where the environments for -a project are. And in the case of a project which has multiple environments, -this PEP is meant to allow for specifying the default environment to use so -users are not forced to make a choice of environment if they do not want to -make such a decision (e.g. at first launch of their code editor). +create/manage virtual environments in order to tell other tools where the +preferred/active virtual environment for a project is. And in the case of a +project which has multiple virtual environments, this PEP is meant to allow for +specifying the default environment to use so users are not forced to make a +choice of environment if they do not want to make such a decision +(e.g. at first launch of their code editor). Please note this PEP neither condones nor discourages having multiple environments for a single project; it is neutral as to whether having a single @@ -78,66 +78,51 @@ is that it is the directory one would open in their code editor to work on a project's code. This could be the directory where the project's :file:`pyproject.toml` lives, or potentially the top directory of a monorepo. -The virtual environment for a project MAY be a path named :file:`.venv` -(i.e. :file:`.venv/pyvenv.cfg` will exist, which can be used to detect the -existence of a virtual environment) in the root of the project. This PEP makes -no judgment whether :file:`.venv` is a physical or logical path to a directory -containing a virtual environment, nor whether logical paths should be resolved -to their physical equivalent before use. - -The root of a project MAY have a :file:`.python-envs` file. This file acts as a -listing of all known environments for the project (sans :file:`.venv`; how that -and :file:`.python-envs` work together will be covered later). The -:file:`.python-envs` MUST be encoded using UTF-8. Each line of the file -represents an environment that is usable by the project and may be separated by -``\n`` or ``\r\n``. A trailing newline of either ``\n`` or ``\r\n`` is allowed -and MUST be ignored. - -Lines in a :file:`.python-envs` file MAY be paths to an environment. Paths MAY -be relative, and if they are, they MUST be relative to the directory containing -the :file:`.python-envs` file. IF a path is for a virtual environment, THEN the -path MUST be to the directory of the virtual environment (i.e. the directory -containing the :file:`pyvenv.cfg` file). A line MAY represent any type of an -environment. Tools reading a :file:`.python-envs` MAY choose what sort of -environments they support and thus MAY ignore any lines they do not -understand (although there is a specific restriction in regards to the default -environment not being supported; covered later). For environments a tool -understands but are somehow malformed (e.g. a virtual environment whose -symlinks no longer resolve), it is up to the tool to decide how to handle such -a situation. There are NO other restrictions on how environments are -represented or what type of environment is in a :file:`.python-envs` file. An -empty file has NO special meaning other than representing the lack of any -environments. - -Duplicate lines MAY be in the file. Listing the same environment multiple times -does NOT carry any meaning. Any tool MAY remove duplicates at any point, but it -MUST maintain what environment is considered the default during de-duplication. - -The last environment listed in a :file:`.python-envs` file MUST be considered -the default environment when a default environment is desired. IF a tool does -not support the last environment listed THEN the tool MUST either ask the user -which environment to use OR error out. - -IF both a virtual environment in a :file:`.venv` directory path and a -:file:`.python-envs` file exist side-by-side, THEN the :file:`.venv` path -MUST be implicitly considered the last line in the :file:`.python-envs` file. -This also means the :file:`.venv` virtual environment is considered the default -virtual environment. - -With regard to committing a :file:`.python-envs` file to version control, it -MAY be done when the location of the environment(s) is considered static +The virtual environment for a project MAY be a directory named :file:`.venv` +(i.e., :file:`.venv/pyvenv.cfg` will exist within the directory, which can be +used to detect the existence of a virtual environment) in the root of the +project. This PEP makes no judgment whether :file:`.venv` is a physical or +logical path to a directory containing a virtual environment, nor whether +logical paths should be resolved to their physical equivalent before use. + +Instead of a directory containing a virtual environment, the root of a project +MAY have a :file:`.venv` redirect file. This file acts as a pointer to where +the (current) virtual environment to be used for the project is located. This +virtual environment may not be the only environment associated with the +project, but it is considered the preferred virtual environment to use +*at the moment* by other tools. The tool managing the virtual environment +SHOULD update any :file:`.venv` redirect file as appropriate when the tool or +the user desire a different virtual environment to be used by default by other +tools. As well, other tools that did not initially create the :file:`.venv` +redirect file SHOULD NOT overwrite it without the user somehow expressing a +desire for the change of "ownership" of the file. + +Tools looking for a virtual environment SHOULD look for either a :file:`.venv` +directory or a :file:`.venv` redirect file. IF a tool chooses to search parent +directories, THEN the closest :file:`.venv` in either form SHOULD be selected. + +A :file:`.venv` redirect file MUST be encoded using UTF-8 (the UTF-8 BOM MUST +NOT be used). The file MUST only contain a single line. A trailing newline of +either ``\n`` or ``\r\n`` is allowed and MUST be ignored. An empty file or one +that only contains a newline is considered invalid. + +The line in the :file:`.venv` redirect file MUST point to a directory +containing a virtual environment. The path MAY use POSIX path separators-- +``/`` --regardless of what the operating system's native path separator is. +The path MAY be relative, and if so MUST be relative to the directory +containing the :file:`.venv` file. + +With regard to committing a :file:`.venv` redirect file to version control, it +MAY be done when the location of the virtual environment is considered static for a project once it is set up. For instance, some projects that use tox_ have a "dev" environment defined in their configuration that ends up at -``.tox/dev``. Setting a :file:`.python-envs` file to point to that virtual +``.tox/dev``. Setting a :file:`.venv` redirect file to point to that virtual environment and checking in the file is reasonable. The same goes for a project -that is only worked on within a container where the location of the +that is only worked on within a container where the location of the virtual environment is controlled and thus static on the file system. The guidance of NOT committing your actual virtual environment to version control is unchanged by this PEP. -Tools MAY use a file system locking mechanism to help guarantee no race -conditions when reading or writing to a :`.python-envs` file. - IF a tool can detect that an environment is already in use (e.g. the ``VIRTUAL_ENV`` environment variable is set), THEN tools SHOULD respect the user's choice and use the activated/in-use environment over the default @@ -145,6 +130,11 @@ environment when no previous environment selection has occurred. Tools MAY choose to override even a previous environment selection if an environment is detected as activated/in use. +This PEP is choosing NOT to take a position on what to do if :file:`.venv` is +invalid (whether it's a directory or a file). It is up to the tool encountering +the invalid directory/file to decide how best to handle the situation. The +expectation, though, is the invalid directory/file will not simply be ignored. + Rationale ========= @@ -158,11 +148,11 @@ Explicitly supporting :file:`.venv` is to codify what's already a convention: - `uv `__ creates environments there already - `Hatch can support `__ - a virtual environment there) + a virtual environment there - `VS Code `__ - will select it automatically, while still allowing configuration + will select it automatically, while still allowing configuration - `PyCharm `__ - will use it + will use it - `GitHub `__ has a default :file:`.gitignore` which ignores :file:`.venv` - `GitLab `__ @@ -171,81 +161,87 @@ Explicitly supporting :file:`.venv` is to codify what's already a convention: has a default :file:`.gitignore` which ignores :file:`.venv` But not every person or tool wants to keep an environment in the project or -even use the :file:`.venv` name. In those situations, you need _some_ way -to tell other tools where to find the environments. That's the purpose of the -:file:`.python-envs` file. The file itself is hidden as it isn't a critical -aspect of the project (environments themselves can be viewed as implementation -details). The file name was chosen to make sure it didn't clash with any other -tool using the same name while still being self-descriptive. - -Allowing for multiple environments came up multiple times during discussions of -this PEP as people said they would switch between multiple environments during -development. Listing all of the environments available instead of a single one -allows for a better UX by allowing tools to present users a list of -environments to choose from. It also helps avoid constant rewriting of the file -recording the single environment that should be used. - -The :file:`.python-envs` file is specifically agnostic when it comes to what -type of environment can be represented. This helps future-proof the file for -unforeseen, future environments. As well, leaving the representation as loose -as what a single line of a file can represent helps with allowing alternative -environments that a tool may or may not support (which can include alternative -representations for virtual environments, e.g. connecting over SSH). It does -mean, though, that tools SHOULD check the line for appropriate use to avoid -using malicious inputs. - -The file format is simple to allow for easy manipulation. Having a -line-delimited file format makes it easy to append a line to a -:file:`.python-envs` file via the terminal, e.g.: - -- ``echo "" >> .python-envs`` -- ``Add-Content .python-envs ""`` -- ``python3 -c "import sys; p=sys.argv[1]; open('.python-envs', 'a').write(p)" ""`` - -To make appending as simple a process as possible, duplicate lines are -allowed to occur in :file:`.python-envs`. This alleviates having to check the -file before appending. This is also why a trailing newline is allowed in the -file. +even use the :file:`.venv` name. In those situations, you need *some* way +to tell other tools where to find the virtual environment to use. That's the +purpose of the :file:`.venv` redirect file. The file itself is hidden as it +isn't a critical aspect of the project (environments themselves can be viewed +as implementation details). The file name was chosen to match the :file:`.venv` +directory name as the purpose of a path with that name is already well known. +As well, it is already broadly ignored by projects, so it won't lead to +projects suddenly having a new file that they may accidentally commit. + +The :file:`.venv` redirect file format is simple to allow for easy +manipulation. It is easy to write a line to a :file:`.venv` file via the +terminal, hence not using a more involved format like JSON. + +POSIX: + +.. code-block:: shell + + realpath "" > .venv + +PowerShell: + +.. code-block:: PowerShell + + (Get-Item '').FullName | Set-Content .venv -Encoding utf8NoBOM + +Python: + +.. code-block:: shell + + python3 -c "import pathlib, sys; p=sys.argv[1]; pathlib.Path('.venv').write_text(str(pathlib.Path(p).resolve()), encoding='utf-8')" "" + +Allowing for the trailing newline also plays into keeping the file format easy +to write. As well, allowing for POSIX-style paths and pointing to the directory +of the virtual environment allows for a cross-platform :file:`.venv` redirect +file when it is committed to version control (i.e., avoiding Windows-style +paths and having tools worry about ``bin/`` versus ``Scripts/``). The file format is also simple to avoid duplicating information that the environment already contains. For instance, it has been suggested to record a -name for environments, but e.g. virtual environments have the prompt recorded -in :file:`pyvenv.cfg`, so it does not need to be listed separately from the -environment where it may become stale. - -This is also why the last line is the default environment: the expectation is -people will be adding the environment they want to use and not simply recording -an available environment. This all tries to make what is expected to be the -most common action the easiest action. - -Having :file:`.venv` represent the last, and thus default, environment in a -:file:`.python-envs` file is for practical reasons. Tools that predate this -PEP may use the :file:`.venv` location, and so this is a -backwards-compatibility consideration. And if a user is using such a tool that -uses :file:`.venv`, then they likely already considered that virtual -environment the default. - -Suggesting tools respect any activate environment is so that users have a way +name or ownership of the virtual environment, but e.g., virtual environments +have the prompt recorded in :file:`pyvenv.cfg`, so it does not need to be +listed separately from the environment where it may become stale. + +While some projects may have multiple virtual environments available, the +concept of a current or default virtual environment is a constant. And saying +other tools shouldn't overwrite a :file:`.venv` redirect file they didn't +create unless explicitly directed by the user is to minimize surprises while +assuming most people will only use a single workflow tool that will be creating +virtual environments. + +Suggesting tools respect any activated environment is so that users have a way to override any potential project-specific default location for an environment -(e.g. a project checks in a :file:`.python-envs` file with a relative path +(e.g., a project checks in a :file:`.venv` file with a relative path while the user very much does not want that location used as they want all environments stored in a centralized location). +By using an explicit name associated with virtual environments, :file:`.venv` +in either form does not interfere with other environment types, e.g., conda +environments. It is acknowledged, though, that this PEP doesn't explicitly help +them either. + Example ======= -If the following contents were in a :file:`.python-envs` file in the -``/workspace`` directory:: - - /absolute/path/to/venv - /a/path/to/conda-env - ssh@example.com:custom-path - relative/path/venv - -The ``relative/path/venv`` directory should be resolved to -``workspace/relative/path/venv``. - +For a project with a single virtual environment at any one time, the workflow +is simple: either place the virtual environment in :file:`.venv` or write out +a :file:`.venv` redirect file. For instance, uv could do this to not only +continue to do its current practice of placing the virtual environment in a +:file:`.venv` directory, but also allow them to place it elsewhere either +because uv's default changes or because the user asked for the file to be +placed elsewhere. + +Other examples are Tox and Nox. Both create multiple virtual environments when +running various tasks. Both tools could provide a way to point a :file:`.venv` +redirect file at the virtual environment of a failed test run to make it easier +to diagnose the failure. And by using a :file:`.venv` file instead of having +users use the virtual environment directly, it lets the tools keep the layout +of where they keep their virtual environments an implementation detail. As +well, both tools could have an easy way to create a default virtual environment +to use in the general case. Project Support for this PEP ============================ @@ -258,9 +254,18 @@ Speaking to various tool maintainers about this PEP: - Supports - 1. VS Code - 2. tox (Bernat Gabor; `PoC `__) - 3. virtualenv (Bernat Gabor; `PoC `__) + 1. PDM (Frost Ming) + 2. Poetry (Randy Döring) + 3. venv (Vinay Sajip) + 4. Virtualenv (Bernát Gábor) + 5. Tox (Bernát Gábor) + 6. `PyCharm `__ (Mark Smith) + 7. `library-skills `__ (Sebastián Ramírez) + 8. `uv `__ (Tomasz Kramkowski) + +- Opposes + + 1. Hatch (Cary Hawkins) Backwards Compatibility @@ -270,19 +275,15 @@ For the virtual environment location aspect of this PEP, there is no backwards compatibility concern as :file:`.venv` is in this PEP specifically for backwards compatibility. -As for :file:`.python-envs`, that file name is not known to be in use. The -biggest backwards compatibility concern is that a tool produces it and it is -not used as expected. After that is the file not being ignored by version -control upfront. +As for :file:`.venv` redirect files, the biggest issue is tools that are not +expecting :file:`.venv` to be a file. The error message in such instances +could be rather obtuse or opaque about why things have gone wrong. But as it +won't implicitly work regardless, it doesn't lead to silent errors either. Security Implications ===================== -Not checking the contents of a potentially malicious :file:`.python-envs` file -and passing it to a shell process (e.g. ``subprocess.run(..., shell=True)``) -would be a serious security concern. - If tools blindly overwrite :file:`.venv`, that could be a denial of service attack if a user happened to use that directory for something else. The expectation, though, is that would occur very rarely due to the convention of @@ -290,6 +291,16 @@ expectation, though, is that would occur very rarely due to the convention of this issue then they can prompt the user before creating an environment at a location that already exists. +Another concern would be using a relative path in a :file:`.venv` redirect file +that is checked into version control. That could result in escaping the project +and somehow using a virtual environment elsewhere on the machine. But +that would require the user to implicitly trust the files in the repository +which is already a security risk. + +Tools need to treat the contents of a :file:`.venv` redirect file as path data +rather than command-line syntax. Interpolating those contents into a shell +command could allow a malicious redirect file to execute arbitrary commands. + How to Teach This ================= @@ -300,11 +311,8 @@ environment on their behalf can do the same. For experienced users, they should be taught that tools may create a virtual environment at :file:`.venv`. They should also be told there may be a -:file:`.python-envs` file which records the location of other environments with -the last environment listed considered the default. As well, they should be -taught that if both :file:`.venv` and :file:`.python-envs` exist in the same -directory then :file:`.venv` is implicitly the last, and thus default, -environment in :file:`.python-envs`. +:file:`.venv` redirect file instead which records the location of the virtual +environment elsewhere. Reference Implementation @@ -317,107 +325,80 @@ speak of. Rejected Ideas ============== -``.venv`` ---------- - Use a name other than ``.venv`` -''''''''''''''''''''''''''''''' +------------------------------- Some people either don't like that ``.venv`` is hidden by some tools by default thanks to the leading ``.``, or don't like ``venv`` as an -abbreviation. Since there doesn't seem to be a clear consensus on an -alternative, a different name doesn't fundamentally change any semantics, -existing tools seem to already support ``.venv``, and one can still use a -different name for an environment thanks to :file:`.python-envs` as proposed by -this PEP. Because the author of this PEP prefers the name, -``.venv`` was chosen. Discussing alternative names was viewed as bikeshedding. - - -``.python-envs`` ----------------- +abbreviation. The relevant considerations are: -A ``.venv`` redirect file -''''''''''''''''''''''''' +1. There doesn't seem to be a clear consensus on an alternative +2. A different name doesn't fundamentally change any semantics +3. Existing tools seem to already support :file:`.venv` +4. One can still use a different name for an environment thanks to + :file:`.venv` redirect files as proposed by this PEP -An earlier version of this PEP allowed for :file:`.venv` to act as a redirect -file to where the virtual environment is located. This was found to be too -restrictive compared to :file:`.python-envs` for a couple of reasons: - -- It supported only a single environment -- It was restricted to only a virtual environment +There doesn't seem to be any specific reason to not use ``.venv`` as a name. +Because the author of this PEP also prefers the name, ``.venv`` was chosen. +Discussing alternative names was viewed as bikeshedding. Recording what tool manages an environment -'''''''''''''''''''''''''''''''''''''''''' +------------------------------------------ -It was suggested to have :file:`.python-envs` record what tool provided an -environment. The thinking was that there was the potential for orphaned +It was suggested to have :file:`.venv` redirect files record what tool provided +an environment. The thinking was that there was the potential for orphaned environments that still existed but were no longer valid for the project after the user moved away from a tool or changed a configuration that wasn't obvious to the user. The decision was made, though, that this was outside of the scope of this PEP -and not worth complicating :file:`.python-envs` for. If a tool wanted to keep -track of what environments they created, that would be up to them to do in -their own way. As for orphaned environments that continued to exist, that would -only be a concern for the default environment as the user would need to choose -any other environment. +and not worth complicating :file:`.venv` redirect files for. If a tool wanted +to keep track of what environments they created, that would be up to them to do +in their own way. As for orphaned environments that continued to exist, that +would only be a concern for the default environment as the user would need to +choose any other environment. Using a more structured format -'''''''''''''''''''''''''''''' +------------------------------ -Using a more structured data format such as JSON for :file:`.python-envs` was -suggested. Typically it was in order to record details about the environment -directly in :file:`.python-envs`. But since that would be redundant data which -could be gathered from the environment itself, it was deemed not a reason to -make the file format more complicated. And the simplicity of the file format +Using a more structured data format such as JSON for :file:`.venv` redirect +files was suggested. Typically it was in order to record details about the +environment directly in :file:`.venv`. But since that would be redundant data +which could be gathered from the environment itself, it was deemed not a reason +to make the file format more complicated. And the simplicity of the file format has helped to keep the goal of the file specific and not have feature creep. Storing the locations in pyproject.toml -''''''''''''''''''''''''''''''''''''''' +--------------------------------------- It was suggested to store the locations of the environment in :file:`pyproject.toml`, but that was rejected as too rigid. Typically an environment location is either a personal choice or a tool-specific one, not a project one. As such, specifying the location statically didn't seem to make enough sense to put into the PEP, especially as a project could include its own -:file:`.python-envs` file. - - -Using the first entry in .python-envs as the default environment -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' +:file:`.venv` redirect file. -It's a subjective choice to have the default environment be at the end of a -:file:`.python-envs` file instead of at the start. The decision came down to -whether reading or writing should be preferred. The PEP chose the latter, -as its author believes that it is more important to make writing to a -:file:`.python-envs` file easier, as a person is more likely to do that than -to read it (the corollary is that, since a tool is more likely to read a -:file:`.python-envs` file via code, reading does not need to be optimized for a -person). -As well, the expectation is that reading even a :file:`.python-envs` file with -hundreds of locations will not visibly hurt performance in any way. +Leave .venv redirect files out of the PEP +----------------------------------------- +Some have suggested leaving :file:`.venv` redirect files out of the PEP (or not +having this PEP at all). But the need for a simple, optional way for a workflow +tool to tell other tools where a project's preferred virtual environment lives, +including when it is outside the project and cannot be reached through a link, +seemed strong enough to keep :file:`.venv` redirect files included. -Leave .python-envs out of the PEP -''''''''''''''''''''''''''''''''' -Some have suggested leaving :file:`.python-envs` out of the PEP (or not having -this PEP at all). But during discussions around this PEP, the desire to have a -way to list the location of multiple environments no matter where they live -seemed strong enough to keep :file:`.python-envs` included. +Support a file name suffix for .venv redirect files +--------------------------------------------------- -Support a file name suffix for .python-envs -''''''''''''''''''''''''''''''''''''''''''' - -There was a suggestion to allow for multiple :file:`.python-envs`-like files, +There was a suggestion to allow for multiple :file:`.venv` redirect files, differing by a file suffix. The idea was to organize what an environment was -named/for. The idea could also be extended to have the files only contain a -single environment. +named/for and allow for multiple virtual environments to be listed. In the end it didn't seem worth the complexity. Environments would have their own way to name themselves, giving some clue as to their contents. As well, @@ -425,6 +406,35 @@ the person choosing which environment to use would not necessarily need such labels. Finally, it could lead to so many files as to be annoying. +Support multiple virtual environments +------------------------------------- + +This PEP was first published supporting :file:`.venv` redirect files, but then +some community pushback led to switching to :file:`.python-envs` files which +allowed for listing multiple virtual environments along with a designated +default environment. The thinking was that enough projects have multiple virtual +environments that listing all of them would be useful while still preserving +the concept of a default/preferred virtual environment. + +Subsequent feedback from some workflow tool authors was that maintaining such a +file would be difficult. If multiple tools were contributing to the file then +there was a risk of workflow tools overwriting each other's work, changing what +the preferred environment was unexpectedly, etc. And with :file:`.python-envs` +meant to capture all available environments, restricting to just a single +workflow tool did not seem reasonable. + + +Support other environment types +------------------------------- + +The :file:`.python-envs` proposal mentioned above was also going to allow +supporting other environment types without requiring such support. The conda +community liked the idea, but without more support it didn't seem worth the +complexity cost. As well, what is proposed in this PEP does not inhibit conda +environment usage and there is a deferred idea that could support conda +environments. + + Deferred Ideas ============== @@ -433,8 +443,8 @@ to come up with a way to standardize how workflow tools could communicate with other tools. This would not only let workflow tools tell other tools where an environment is, but also create environments, run commands in an environment, etc. Conversations went far enough to -`vote on communication protocols `__ -and `continue that discussion `__. +`vote on communication protocols `__ +and `continue that discussion `__. In the end, though, it was decided this PEP could stand on its own without such a tool-to-tool protocol which would be a massive endeavour. But the name of @@ -454,6 +464,10 @@ this PEP. Change History ============== +- 08-Sep-2026 + + - Switch back to :file:`.venv` redirect files from :file:`.python-envs` files + - 10-Aug-2026 - Clarify that relative paths in :file:`.python-envs` are against the