Title: [venv] Add ~/.venvrc to change module defaults
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.9
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Epic_Wink, brett.cannon, cooperlees, eryksun, vinay.sajip
Priority: normal Keywords: patch

Created on 2019-10-15 10:51 by cooperlees, last changed 2019-11-23 16:44 by cooperlees. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 16802 closed cooperlees, 2019-10-15 13:00
Messages (7)
msg354712 - (view) Author: Cooper Lees (cooperlees) * Date: 2019-10-15 10:51
I'd like to propose adding a run commands (.venvrc) file support to the venv library.

File Location: `~/.venvrc`

This file will support all current CLI arguments and override the defaults for each CLI if present in the file. I will also endeavour to add test for POSIX + Windows systems.

I propose using `configparser` and an `.ini` style config for the `.venvrc`.

My main use for this is to allow myself to default to always using `--upgrade-deps` when I create new venvs.

Thoughts? Concerns?
msg355115 - (view) Author: Laurie Opperman (Epic_Wink) * Date: 2019-10-22 03:27
".xxxxxrc" usually means a file to be run (by a shell) at shell start, and therefore is a script of command to run ("rc" seems to come from "runcom", ie run commands).

INI files usually have a ".ini" or ".cfg" suffix. `virtualenv`, for example, used an INI file similar to your proposal:
msg355116 - (view) Author: Cooper Lees (cooperlees) * Date: 2019-10-22 03:50
Good point. Happy to match the virtualenv module and use `.ini` if others agree.
msg355117 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-10-22 06:02
In Windows, dot files cannot be hidden (i.e. set the hidden file attribute), unlike how they're conventionally hidden in Unix. Doing so breaks normal access. A directory such as ".venv" can be hidden, but that's still going against convention. For Windows, I suggest using "$APPDATA/Python/venv.ini" as the default path. 

Note that, while "$APPDATA/Python" happens to be the base directory for per-user package installations, i.e. site.getuserbase(), I'm not suggesting to use the user base directory as the default in Unix and macOS systems. 

For comparison, pip uses "$APPDATA/pip/pip.ini" in Windows and "$HOME/.config/pip/pip.conf" in Unix. In macOS it prefers "$HOME/Library/Application Support/pip" over "$HOME/.config/pip" if the former exists.
msg355592 - (view) Author: Cooper Lees (cooperlees) * Date: 2019-10-28 20:20
Updated PR to use venv.ini. Will fix any CI errors encountered.
msg357348 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2019-11-23 00:12
Is this best served in the stdlib or in an external tool like how virtualenvwrapper is separate from virtualenv? While I get the convenience of not having to install another tool to do this, it does bring in some complexity that does not directly tie into the metadata required by venv to write out to pyvenv.cfg or the directories and files that it creates.
msg357360 - (view) Author: Cooper Lees (cooperlees) * Date: 2019-11-23 03:27
I vote in the stdlib. This is the biggest win of venv over virtualenv The aim of this request is to allow developers to customize some of the venv defaults to make it easier to move from project to project.

To ensure a clean development environment, some days I create multiple venvs (virtual environments) a day. I treat my venv's ephemeral, and I am sure many other do too. Being able to set `--upgrade-deps` and/or other defaults via a config file just saves a few more key strokes and allows Python to be even more delightful to develop in over other languages.

In regards to you bringing up pyenv.cfg + metadata, this attacks a totally different problem. This is allowing developers to set some defaults for venv creation. It does not change any internal meta data and is just an optional optimization developers can choose to use.
Date User Action Args
2019-11-23 16:44:56cooperleessetstatus: open -> closed
resolution: rejected
stage: patch review -> resolved
2019-11-23 03:27:52cooperleessetmessages: + msg357360
2019-11-23 00:12:39brett.cannonsetnosy: + brett.cannon
messages: + msg357348
2019-10-28 20:20:33cooperleessetmessages: + msg355592
2019-10-22 06:02:22eryksunsetnosy: + eryksun
messages: + msg355117
2019-10-22 03:50:22cooperleessetmessages: + msg355116
2019-10-22 03:27:33Epic_Winksetnosy: + Epic_Wink
messages: + msg355115
2019-10-15 13:14:16xtreaksetpull_requests: - pull_request16359
2019-10-15 13:13:57xtreaksetnosy: + vinay.sajip
2019-10-15 13:05:03cooperleessetpull_requests: + pull_request16359
2019-10-15 13:00:43cooperleessetkeywords: + patch
stage: patch review
pull_requests: + pull_request16358
2019-10-15 10:51:40cooperleescreate