Re:Goodbye Python Virtual Environments
by joshuamorton on Tuesday February 05, 2019 @09:35PM
(#19092209)
Just fyi, using pypi download statistics is something that no one reputable does. They're dominated by mirrors and automated tools, not by actual downloads. http://py3readiness.org/ is what you should look at, which shows that 359 of the 360 most popular packages support Python 3, or have a drop in replacement that does. The one remaining, apache-beam, is actively working on finalizing Python 3 support, (and in practice, already does support Python 3).
Most people in python-land don't want to package their stuff as rpm or dep packages because linux isn't the only environment they run on. When .debs can be installed on OSX and windows, that might make sense, but until then, cross-platform distribution is probably going to be seen as the superior way for most devs.
>goes in the same directory as the script, and those typically live in bin/
For most python scripts, the thing in `bin/` is a stub that invokes a library in site-packages or sometimes in a specific venv, depending on the install method. So I'd expect that no, the script would keep doing what it does, and __pypackages__ would exist inside of the python package eventually invoked.
>What are those challenges? C-extensions that need custom compilation options and all that stuff.
These are fundamental challenges for only a very small subset of people (even fewer now that the CFFI is a thing).
You're asking python to be nicer for your specific usecase which appears to be python with C++ extension development on linux at the disadvantage of everyone who isn't on linux and who doesn't write extension modules. (and even within that area, I'd argue that cython or CLIF atop Bazel or Pants is still superior to handwritten extension modules atop cmake, so you're asking python to double-down on a not-the-best solution).
You're correct that they shouldn't splinter the community, but all of your suggestions would do just that.
Most people in python-land don't want to package their stuff as rpm or dep packages because linux isn't the only environment they run on. When .debs can be installed on OSX and windows, that might make sense, but until then, cross-platform distribution is probably going to be seen as the superior way for most devs.
>goes in the same directory as the script, and those typically live in bin/
For most python scripts, the thing in `bin/` is a stub that invokes a library in site-packages or sometimes in a specific venv, depending on the install method. So I'd expect that no, the script would keep doing what it does, and __pypackages__ would exist inside of the python package eventually invoked.
>What are those challenges? C-extensions that need custom compilation options and all that stuff.
These are fundamental challenges for only a very small subset of people (even fewer now that the CFFI is a thing).
You're asking python to be nicer for your specific usecase which appears to be python with C++ extension development on linux at the disadvantage of everyone who isn't on linux and who doesn't write extension modules. (and even within that area, I'd argue that cython or CLIF atop Bazel or Pants is still superior to handwritten extension modules atop cmake, so you're asking python to double-down on a not-the-best solution).
You're correct that they shouldn't splinter the community, but all of your suggestions would do just that.