4 ms·
There is Python, then there is the tooling around Python. Virtual environments constitute tooling around Python. Sometimes aspects of the tooling become indispe
by has2k1 10y ago
There is Python, then there is the tooling around Python. Virtual environments constitute tooling around Python. Sometimes aspects of the tooling become indispensable and they are adopted as part of the standard library -- see venv.
You may not realise it, but Python usage patterns have changed significantly over the last 6-8 years and they are still changing. With such change, it is hard to create any tooling that is concrete and stable over the long term. By that same reason not a lot of tooling can be adopted by the standard library.
- m_mueller 10y agoI can see that reasoning given how Python started, but since Python3 broke backwards compatibilities anyways it should IMO have solved the whole packaging, versioning and isolation problem once and for all through standard utilities delivered with every Python distro.
- has2k1 10y agoIf there are no agreed upon proposals, then why implement solutions if their utility would still be inadequate. It is not enough to demand perfect solutions, there must be perfect proposals.
- m_mueller 10y agoWell, sometimes you need an architect rather than a committee. This is one such time. Looking at the whole thing superficially (i.e. just throwing something at the wall here), this is how I'd have done it: * packages are by default always installed in user space. * package manager is built into import system. Importing a package that's not in the user's environment yet will lead to something like pip install at script startup. * import statements understand versions. By default the latest version of a package is loaded. If something else is needed, the programmer can specify the specific one. * for most third party packages that are publicised in pypy it's recommended to bind all imports to specific versions of dependencies, so it can be tested in this configuration at release.
- devnonymous 10y ago> package manager is built into import system. > Importing a package that's not in the user's > environment yet will lead to something like > pip install at script startup Here's a nifty little recipe I came up with to do just this by exploiting the import hooks introduced in py3.4 http://lonetwin.github.io/blog/html/2016/05/16/auto_install_missing_python_modules.html
- maweki 10y agoPlease don't do that. Provide a requirements-file with the appropriate dependencies and their versions to use with `pip install -r `