[Mehdi2277]

It’s opposite. Venv is built into python and part of standard library. It is part of cpython repo and developed by python maintainers. Some Linux distributions remove it from standard library but windows/Mac always has it. The Linux distributions that have python without venv are considered incomplete python install and packaging community has considered not supporting that case in future. At moment pip tries to allow that case but in future may just require venv and consider Linux distributions that remove it as shipping a problematic python.

[crabbone]

> It’s opposite. Venv is built into python and part of standard library.

Well, you simply don't know your stuff, but are overcome with confidence... where have I seen this before?

Let's start with this: standard library (without quotes) means there's a standard that describes a collection of library functions that constitute a standard library. Python doesn't have a standard. Well, technically, there isn't really Python, there are Pythons. Each accepted PEP that deals with the language creates new language, they are just similar enough that they all, collectively, can be referred to as "Python" for many practical purposes.

Python is notorious for its vague and incoherent use of nomenclature. It doesn't follow its own definitions, but it also doesn't create good definitions to begin with. Someone in Python's history decided to call a chunk of Python's token implementation "the standard library", and the term stuck. But, in reality, nothing makes code found in CPython repository a standard, nor is it even in any way prescriptive for other implementations.

There's a bunch of other code that's optionally included or enabled in the "standard library", and there's no formal document that describes what should be included. In particular, there are a bunch of features that are only enabled by compilation switches (eg. various garbage collection helpers). And you cannot possibly argue that a mere presence of those features in CPython's source code somehow makes them necessarily a part of the "standard library", because then the very definition of "standard library" becomes contingent on the compiler options you provided when compiling Python.

Now, whatever pip authors think is "standard library" or "complete" or "incomplete" Python distribution shouldn't bother anyone really. Their opinion is just as valid as mine or that of my cat: none of us defines nor controls what any of those things are.

Subsequently: who told you that there aren't any Windows or Mac distributions that don't have venv? I can easily make however many I want. But, most importantly, again, who cares? Why does it even matter? To show that venv isn't a necessary part of something, it's enough to find a single example where it's not included, you don't need to search for places where it's included...

[Mehdi2277]

Python documentation defines standard library and includes venv, https://docs.python.org/3/library/venv.html, as part of it. There is also python steering council/core developer group that has had discussions with debian/other distributions about this issue and considered those versions of python incomplete. The docs.python.org is pretty much formal document comparable to how c++ has cppreference for defining standard library.

It matters in sense that packaging/python tooling may in future treat your distribution that's not included as not supported use case and just reject it. Distribution made by vendor can do whatever it wants, but I do consider calling it python implementation problematic at that point. If vendor can change implementation of python however they like and remove large subsets of it, then name has little meaning.

[crabbone]

There's so much wishful thinking in what you write...

No, and no, and no.

Nobody cares what Python documentation defines: it's not a standard. Python doesn't have a standard. It's convenient to not have a standard, especially if you don't know what you are doing (and I don't use this pejoratively). This makes things more flexible. This, particularly, benefits you if you only ever have one implementation, because it creates a lot of room for experiments.

This, of course, hampers community contribution. If you don't have standards, you cannot have competing compilers or interpreters: there will always be a flagship and those trailing far, far behind. Standards also ensure that come what may, in the future, you will be able to reproduce you work, if you followed the standard. Otherwise, well, you have Python. Today, you can no longer build Python 3.6 on a modern Linux (I might be wrong, and it's 3.5, don't take my word for it, but it's surprisingly recent), and the current version of Python will not run code written for 3.6. So, you end up with useless code. And, since we are talking about Python, the volume of useless code is astounding.

Compare this to, eg. Linux kernel which is written in C89. Python didn't even exist when this standard was created. Consider what will happen if you try to run code written for Python 2.0 (I think this was the first public release?) today? -- This is how you know the difference between having a standard and not having it.

----

PS. And of course, you chose to link to something irrelevant. However, this is what you "forgot" to link to:

> The Python installers for the Windows platform usually include the entire standard library and often also include many additional components. For Unix-like operating systems Python is normally provided as a collection of packages, so it may be necessary to use the packaging tools provided with the operating system to obtain some or all of the optional components.

Taken from https://docs.python.org/3/library/index.html

I couldn't find where Python documentation defines what's "optional" in its "standard" library. So, there's no reason to believe that "venv" is in "standard" library or not. Even the authors aren't sure, but, ironically, the authors don't have the authority to tell one way or the other.

[theptip]

Your demeanor here is quite argumentative and condescending; I'd suggest you (re?)read the HN guidelines. If you want to vent a diatribe to feel better, please do it to your rubber duck instead of here.

```

Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

Please don't fulminate. Please don't sneer, including at the rest of the community.

Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

```