{"action":"created","issue":{"url":"https://api.github.com/repos/pypa/virtualenv/issues/719","labels_url":"https://api.github.com/repos/pypa/virtualenv/issues/719/labels{/name}","comments_url":"https://api.github.com/repos/pypa/virtualenv/issues/719/comments","events_url":"https://api.github.com/repos/pypa/virtualenv/issues/719/events","html_url":"https://github.com/pypa/virtualenv/issues/719","id":58565462,"number":719,"title":"create a pyvenv.cfg file like the venv module","user":{"login":"wm75","id":4742081,"avatar_url":"https://avatars.githubusercontent.com/u/4742081?v=3","gravatar_id":"","url":"https://api.github.com/users/wm75","html_url":"https://github.com/wm75","followers_url":"https://api.github.com/users/wm75/followers","following_url":"https://api.github.com/users/wm75/following{/other_user}","gists_url":"https://api.github.com/users/wm75/gists{/gist_id}","starred_url":"https://api.github.com/users/wm75/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wm75/subscriptions","organizations_url":"https://api.github.com/users/wm75/orgs","repos_url":"https://api.github.com/users/wm75/repos","events_url":"https://api.github.com/users/wm75/events{/privacy}","received_events_url":"https://api.github.com/users/wm75/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-02-23T10:05:06Z","updated_at":"2015-02-23T11:32:31Z","closed_at":null,"body":"The stdlib venv module generates a pyvenv.cfg file inside the virtual environment's main folder. This file stores information about the virtual environment such as the original python that the environment was cloned from (and which will provide the standard library) and the version of the interpreter.\r\n\r\nvirtualenv, instead, places a modified site.py in the environment to make the isolated interpreter use its home stdlib so it does not depend on a config file 'home' key.\r\n\r\nHowever, the 'version' information could still be useful. Specifically on Windows, where the interpreter executable names do not provide version hints, there is currently no simple way to find out what interpreter version is used by a virtualenv without running the interpreter, while for a virtual environment created with venv one can simply inspect the pyvenv.cfg file.\r\n\r\nA specific case, in which this information could be useful, is discussed on the python bug tracker - http://bugs.python.org/issue23465 (related to [PEP486](http://www.python.org/dev/peps/pep-0486/)) - and concerns inspection of the virtual environment by the py launcher.\r\n\r\nIt should also be noted that the current rewrite branch uses the venv module when available and will, thus, generate the pyvenv.cfg file anyway. So having the file created by the legacy builder would also improve consistency.\r\nFor this reason, I think the rewrite branch would also be the obvious branch to introduce this feature, but it could be added to the development branch, too.\r\n\r\nI could certainly provide a PR if needed, but I would first like to know which repo branch to target."},"comment":{"url":"https://api.github.com/repos/pypa/virtualenv/issues/comments/75526734","html_url":"https://github.com/pypa/virtualenv/issues/719#issuecomment-75526734","issue_url":"https://api.github.com/repos/pypa/virtualenv/issues/719","id":75526734,"user":{"login":"pfmoore","id":1110419,"avatar_url":"https://avatars.githubusercontent.com/u/1110419?v=3","gravatar_id":"","url":"https://api.github.com/users/pfmoore","html_url":"https://github.com/pfmoore","followers_url":"https://api.github.com/users/pfmoore/followers","following_url":"https://api.github.com/users/pfmoore/following{/other_user}","gists_url":"https://api.github.com/users/pfmoore/gists{/gist_id}","starred_url":"https://api.github.com/users/pfmoore/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pfmoore/subscriptions","organizations_url":"https://api.github.com/users/pfmoore/orgs","repos_url":"https://api.github.com/users/pfmoore/repos","events_url":"https://api.github.com/users/pfmoore/events{/privacy}","received_events_url":"https://api.github.com/users/pfmoore/received_events","type":"User","site_admin":false},"created_at":"2015-02-23T11:32:31Z","updated_at":"2015-02-23T11:32:31Z","body":"1. Well, not really, as any code wanting to check would then need to look for either file. It's OK, but more messy than I'd like, and whether it's an acceptable level of messiness depends on what code ends up using it (we have at best one use case so far, see below for comments).\r\n2. Yes, my point was that someone needs to do the research. Checking pep 405 it's *not* OK to use the same filename as that would trigger the core Python virtualenv support. Don't forget you have to consider the possibility of a pre-rewrite virtualenv (unless this issue gets deferred until after the rewrite lands, which is an option).\r\n3. Point 3 should not be discussed here, but as part of proposing the feature for core Python (which needs at a minimum a new item on bugs.python.org, likely also a proposed patch, and quite possibly even a PEP). It's a controversial proposal, and I, for one, am currently against it, not least because it needs a virtualenv change to in order to work properly.\r\n\r\nTaken in isolation, I was +0 on this change (it's never a bad thing to record information others might want to use, even though there is no actual use case that I agree with), but the fact that it needs to use a different filename is a point against it, and I'm starting to think it's not worth the effort."}}