|
|
|
|
|
|
by avidphantasm
460 days ago
|
|
|
I have been using Python for 20 years, and have been an intermediate to advanced user of it for last 5-7 years. I use it mostly for scientific computing (so lots of Numpy, SciPy, etc.), IoT data processing, and also for some microservices that don’t need to be super fast. I publish and maintain a few packages in PyPI and conda (though I almost never use conda myself), including a C++ library with Python bindings generated by SWIG (SWIG wouldn’t be my first choice, but I inherited it). In what I’ve done, I’ve never found things like pipenv, let alone uv, to be necessary. Am I missing something? What would uv get? |
|
|
The selling point of uv is that it does things faster than the tools it aims to replace, but on a conceptual level it doesn't add anything substantially new. The tools it aims to replace were borne of the defects in Python import and packaging systems (something that Anaconda also tried to address, but failed). They are not good tools designed to do things the right way. They are band-aids designed to mitigate some of the more common problems stemming from the bad design choices in the imports and packaging systems.
My personal problem with tools like uv is that, just like Web browsers in the early days of the Web tried to win users by tolerating the mistakes made by the Web site authors, it allows to delay the solution of the essential problems that exist in Python infrastructure by offering some pain relief to those who are using the band-aid tools.