I don't like extending "pyvenv.cfg" with generic settings. This is a
file to configure a virtual environment
Yes indeed.
in terms of finding the
standard library and packages.
But why limit it to that? If there are more things to configure in an environment-specific way — why not put it in this existing location?
I'd prefer a new configuration file that sets the default values for
-X implementation-specific options. The mechanism for finding this
file can support virtual environments.
Then wouldn’t that simply be two configuration files that will be treated the same way?
> This is the problem that I was thinking about when I proposed using
> a py.ini like solution where the file is looked for in the users config
> folder. I think that is the %LOCALAPPDATA% folder for py.exe.
I’m still convinced that It is a bad idea to have User-wide Python configuration like this. The fact is that different Python apps (may) need different configurations, and environments are the way to support that.
Yes, not everyone uses virtual environments, but I see that as some people use only one environment— rather than not using environments at all.
So it would be really good to have a single environment be configured the same way as multiple environments.
This would also work better with conda environments, which work at a “higher” level: there could be any number of instances of, say, Python 3.9.6 - and each could potentially need a different configuration: having them all reference the same place in %LOCALAPPDATA% folder would be a mess.
I know it seems like I’m advocating breaking from the standards already established outside of Python, but we need to remember that Python is not an application, it is a run-time environment that may support multiple applications. If there are standards for configuration of similar things, then we should look at those.
Final point for emphasis:
It would be really great if the chosen solution supported conda (and maybe other) environments well.
-Chris B