#venv discovery standardisation

1 messages ยท Page 1 of 1 (latest)

cunning galleon
worthy iron
#

Any reason not to just update pyvenv.cfg with what you want?

#

And what exactly are you wanting to capture? My guess is it doesn't play into my motivating use case, so "no", but who knows (besides, you've written more PEPs than me so you know how to make it happen ๐Ÿ˜‰).

#

Or are you just trying to get a file version of [tool]?

cunning galleon
#

Working out how to run Python in a venv in a cross platform way is annoying, as is finding the various sysconfig paths. So I'd like a JSON file (edit: in a well-defined cross-platform location) inside the venv that specifies where to find the Python binary and all the sysconfig paths relative to the base of the venv.

New file vs pyvenv.cfg is a combination of "ini files are a pain" and "this is for venv consumers, not the interpreter"

#

Oh, and knowing the expected Python version and target platform, since those are what we would need for improved error reporting when a venv is moved to an incompatible system.

#

Also offering a venv tool metadata equivalent is why share/venv/venv.json is inside a directory (venvstacks already emits share/venv/venvstacks.json in the venvs it builds)

worthy iron
#

Yeah, I'll take a pass at trying to roll that into my PEP and let the #1 PEP author tackle if she wants to ๐Ÿ˜‰