| > 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... |
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.