4 ms·

Because uv is excellent in some ways and good in all ways. Pretty much all other package managers suck in some way. > confusingly named The name needs to be u

Because uv is excellent in some ways and good in all ways. Pretty much all other package managers suck in some way. > confusingly named The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. > Python has turned from a community language into a company-led one That's quite a radical take, reducing a language to it's package manager and linter. > backed by a for-profit company so is VS Code

TeMPOraL 2y ago
> The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. So? 3 letters isn't some magic cutoff; cutting your command down to 3 letters or less doesn't make it suddenly 10x more effective for its users. 4 or 5 letters would be fine, too. > That's quite a radical take, reducing a language to it's package manager and linter. Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation. The trend in the last couple decades is to, in fact, make all three part of the core, under purview of the same person or group that designs the language itself, and its standard library. I.e. if you want to "own" the future of a language, the second best option after owning the most popular runtime, is to own the most popular package manager. And I can see this happening already in discussion threads about Python I've been reading over past few months. It's not just that people are excited about UV itself, they're treating Astral as a "thought leader" now. Again, I'm not saying it's bad, or that Astral would be a bad steward. I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship. > so is VS Code VS Code is its own thing; sure, it sucked oxygen out of IDE space on UI front, but it also competes against JetBrains in the same space, plus, thanks to LSP, it revitalized Vim and Emacs as viable competitors and enabled creation of even more editors. In contrast, UV just put a single company in the core position to influence the direction Python as a language takes, which is a new situation for Python - one of the last few popular languages that didn't have a corporate benefactor to start and push it into popularity.
- dist-epoch 2y ago
  > UV just put a single company in the core position to influence the direction Python as a language takes I would argue VS Code where the most popular extension is for the Python language has more influence than Astral.
- zahlman 2y ago
  >Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation.... I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship. This seems to represent a schism in the community, although not a constantly explicit one that's pointed at as the cause of conflict (like with, say, the debate over the role of Rust in the Linux kernel). The original community is so "diverse/anarchic" - and so old - that it causes friction with that first assertion. As far as I know, the idea of a "package manager" being particular to a programming language (as opposed to the operating system) is much newer than Python itself. I was able to use Python for many years before anyone ever suggested a linter to me, either. (Granted, the original lint program for C is from the 70s, but it wasn't seen as a necessity back then - not a compulsory part of a software engineering education, and certainly not treated as fundamental. Actually, I still don't use one.) And I'm still nowhere near "original", having really started using Python in the mid 2000s. In that frame, it's hard to get people to agree on a project manager, because they don't even agree on the concept of a "project". People write code that they never plan to share with others. People write code that they only expect to share with real-life associates, and don't have the tools to understand why it "only works on my machine" - if you don't have the mental concept of dependencies, you aren't going to be able to specify them, nor properly use a tool to manage them. People just write a few `.py` files in a directory somewhere and expect them to play nice with each other and don't understand why they're shadowing the standard library. On the other end of the spectrum, people need to interface Python with code in C, FORTRAN and all sorts of other dinosaurs, and they still don't yet have a way to specify their dependencies properly. (Before 2018 or so, there wasn't even a clearly delineated concept of build-time vs runtime dependencies, and people would get into weird chicken-and-egg situations because of needing to run `setup.py` in order to find out what packages are required to run `setup.py`. And now they still run into those problems, because they resist the new changes because of the "useless churn" of `pyproject.toml`.) Sometimes you can hack around that because wheel contents can be anything (including compiled C libraries), but Pip still isn't going to install a custom C compiler into `/usr/bin` (or, heaven forbid, set one up on Windows). And then you have people with giant monorepos trying to figure out where to put `pyproject.toml` files to describe separate "projects" within the same superstructure and build all the separate wheels they want.

TeMPOraL 2y ago

> The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. So? 3 letters isn't some magic cutoff; cutting your command down to 3 letters or less doesn't make it suddenly 10x more effective for its users. 4 or 5 letters would be fine, too. > That's quite a radical take, reducing a language to it's package manager and linter. Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation. The trend in the last couple decades is to, in fact, make all three part of the core, under purview of the same person or group that designs the language itself, and its standard library. I.e. if you want to "own" the future of a language, the second best option after owning the most popular runtime, is to own the most popular package manager. And I can see this happening already in discussion threads about Python I've been reading over past few months. It's not just that people are excited about UV itself, they're treating Astral as a "thought leader" now. Again, I'm not saying it's bad, or that Astral would be a bad steward. I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship. > so is VS Code VS Code is its own thing; sure, it sucked oxygen out of IDE space on UI front, but it also competes against JetBrains in the same space, plus, thanks to LSP, it revitalized Vim and Emacs as viable competitors and enabled creation of even more editors. In contrast, UV just put a single company in the core position to influence the direction Python as a language takes, which is a new situation for Python - one of the last few popular languages that didn't have a corporate benefactor to start and push it into popularity.

dist-epoch 2y ago
> UV just put a single company in the core position to influence the direction Python as a language takes I would argue VS Code where the most popular extension is for the Python language has more influence than Astral.
zahlman 2y ago
>Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation.... I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship. This seems to represent a schism in the community, although not a constantly explicit one that's pointed at as the cause of conflict (like with, say, the debate over the role of Rust in the Linux kernel). The original community is so "diverse/anarchic" - and so old - that it causes friction with that first assertion. As far as I know, the idea of a "package manager" being particular to a programming language (as opposed to the operating system) is much newer than Python itself. I was able to use Python for many years before anyone ever suggested a linter to me, either. (Granted, the original lint program for C is from the 70s, but it wasn't seen as a necessity back then - not a compulsory part of a software engineering education, and certainly not treated as fundamental. Actually, I still don't use one.) And I'm still nowhere near "original", having really started using Python in the mid 2000s. In that frame, it's hard to get people to agree on a project manager, because they don't even agree on the concept of a "project". People write code that they never plan to share with others. People write code that they only expect to share with real-life associates, and don't have the tools to understand why it "only works on my machine" - if you don't have the mental concept of dependencies, you aren't going to be able to specify them, nor properly use a tool to manage them. People just write a few `.py` files in a directory somewhere and expect them to play nice with each other and don't understand why they're shadowing the standard library. On the other end of the spectrum, people need to interface Python with code in C, FORTRAN and all sorts of other dinosaurs, and they still don't yet have a way to specify their dependencies properly. (Before 2018 or so, there wasn't even a clearly delineated concept of build-time vs runtime dependencies, and people would get into weird chicken-and-egg situations because of needing to run `setup.py` in order to find out what packages are required to run `setup.py`. And now they still run into those problems, because they resist the new changes because of the "useless churn" of `pyproject.toml`.) Sometimes you can hack around that because wheel contents can be anything (including compiled C libraries), but Pip still isn't going to install a custom C compiler into `/usr/bin` (or, heaven forbid, set one up on Windows). And then you have people with giant monorepos trying to figure out where to put `pyproject.toml` files to describe separate "projects" within the same superstructure and build all the separate wheels they want.