3 ms·

> You don't even need to know there is a venv, or what activation means. > All those commands update the lock file automatically and transparently.... It's all

> You don't even need to know there is a venv, or what activation means. > All those commands update the lock file automatically and transparently.... It's all taken care of. When is the python community going to realize that simple is the opposite of easy? I don't see how hiding these aspects is desirable at all; I want to know how my programming tools work! With all due respect to the author, I don't like the assumption that all programmers want magic tools that hide everything under the rug. Some programmers still prefer simplicity, ie understanding exactly what every part of the system does. Nothing against uv, it seems like a fine tool. And I'm sure one could make a case for it on other technical merits. But choosing it specifically to avoid critical thinking is self-defeating.

ijustlovemath 2y ago
I think that when you, as most HN commenters are wont to do, are trying to achieve a certain level of mastery in your craft, you're going to want to dive deep, understand the abstractions, have full control, be able to start with nothing but a UDP socket and a steady hand, but that approach misses a huge number of users of these languages. You don't want scientists to have to worry about setting up a venv, you want them to analyze their data and move on with their lives. Sure, people like you or me will be able to setup and source a venv in no time, without expending much mental energy, but we're not who this product is for. It's for the rest of the users, the 99% who aren't even aware places like this exist. All that said, I'm pretty skeptical of using uv until their monetization strategy is clear. The current setup is making me think we're in for a Docker-like license change.
392 2y ago
There is simplicity of interface and then of implementation. If you try uv you will find it is both convenient and easier to understand than competing solutions, because everything _just works_ and you find the proof of how it works waiting in your `git status`. You can be assisted in knowing that it just works because its install takes no time and no system setup. It is slick.
zahlman 2y ago
A recurring theme I've seen in Python packaging community discussion is that a lot of people really seem to hate venvs, mostly for reasons I consider quite irrational. And if they don't outright hate the things, they fear having to try to explain them to newbies. Keep in mind: there are huge numbers of people out there who will cargo-cult about how applying the sudo hammer to Pip fixed something or other (generally, because the root user has different environment variables). People even resent having to do user-level installations; they resent venvs even more. When the Python team collaborated with multiple Linux distros to add a system to protect against global user-level installs (because they were still interfering with system Python tools), a lot of people reacted by doing whatever they could to circumvent that protection, and advising each other on how to do so - thus the education effort described in https://discuss.python.org/t/the-most-popular-advice-on-the-internet-for-error-externally-managed-environment-is-to-force-packages-to-be-system-installed/56900 https://discuss.python.org/t/the-most-popular-advice-on-the-... . People really would, apparently, rather add `--break-system-packages` to a command line so that they can keep installing everything in the same place, than attempt to understand even the basics of environment management. And we're talking about programmers here, mind. And then there are the complaints about how the __pypackages__ proposal (https://peps.python.org/pep-0582/ https://peps.python.org/pep-0582/) failed - e.g. https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/#pep-582-the-future-of-python-packaging https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth... . There were serious issues with that idea, which only became clear as the discussion dragged on and on across literally years (https://discuss.python.org/t/pep-582-python-local-packages-directory/963 https://discuss.python.org/t/pep-582-python-local-packages-d...). But people were quite upset about having to stick with the old venv model - including the guy who wrote the best explanation of venvs I know, which I frequently refer beginners to (https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi...). A lot of programmers seem to love having the details not only hidden, but as inaccessible as possible, as long as the UI is nice enough. (Unless we're talking about their own code. Then, hundred-line functions are just hunky-dory.)

ijustlovemath 2y ago

I think that when you, as most HN commenters are wont to do, are trying to achieve a certain level of mastery in your craft, you're going to want to dive deep, understand the abstractions, have full control, be able to start with nothing but a UDP socket and a steady hand, but that approach misses a huge number of users of these languages. You don't want scientists to have to worry about setting up a venv, you want them to analyze their data and move on with their lives. Sure, people like you or me will be able to setup and source a venv in no time, without expending much mental energy, but we're not who this product is for. It's for the rest of the users, the 99% who aren't even aware places like this exist. All that said, I'm pretty skeptical of using uv until their monetization strategy is clear. The current setup is making me think we're in for a Docker-like license change.

392 2y ago

There is simplicity of interface and then of implementation. If you try uv you will find it is both convenient and easier to understand than competing solutions, because everything _just works_ and you find the proof of how it works waiting in your `git status`. You can be assisted in knowing that it just works because its install takes no time and no system setup. It is slick.

zahlman 2y ago

A recurring theme I've seen in Python packaging community discussion is that a lot of people really seem to hate venvs, mostly for reasons I consider quite irrational. And if they don't outright hate the things, they fear having to try to explain them to newbies. Keep in mind: there are huge numbers of people out there who will cargo-cult about how applying the sudo hammer to Pip fixed something or other (generally, because the root user has different environment variables). People even resent having to do user-level installations; they resent venvs even more. When the Python team collaborated with multiple Linux distros to add a system to protect against global user-level installs (because they were still interfering with system Python tools), a lot of people reacted by doing whatever they could to circumvent that protection, and advising each other on how to do so - thus the education effort described in https://discuss.python.org/t/the-most-popular-advice-on-the-internet-for-error-externally-managed-environment-is-to-force-packages-to-be-system-installed/56900 https://discuss.python.org/t/the-most-popular-advice-on-the-... . People really would, apparently, rather add `--break-system-packages` to a command line so that they can keep installing everything in the same place, than attempt to understand even the basics of environment management. And we're talking about programmers here, mind. And then there are the complaints about how the __pypackages__ proposal (https://peps.python.org/pep-0582/ https://peps.python.org/pep-0582/) failed - e.g. https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/#pep-582-the-future-of-python-packaging https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth... . There were serious issues with that idea, which only became clear as the discussion dragged on and on across literally years (https://discuss.python.org/t/pep-582-python-local-packages-directory/963 https://discuss.python.org/t/pep-582-python-local-packages-d...). But people were quite upset about having to stick with the old venv model - including the guy who wrote the best explanation of venvs I know, which I frequently refer beginners to (https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/ https://chriswarrick.com/blog/2018/09/04/python-virtual-envi...). A lot of programmers seem to love having the details not only hidden, but as inaccessible as possible, as long as the UI is nice enough. (Unless we're talking about their own code. Then, hundred-line functions are just hunky-dory.)