4 ms·

Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and

Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. Between this and other tooling from that same company, it feels to me that, in the space of less than a year, Python has turned from a community language into a company-led one (like. e.g. Scala). Not saying whether it's good or bad - just that it's damn curious how this played out. It feels like Python leadership got taken over by some company almost overnight; I'd love to understand how did this happen. -- [0] - Arguably an outsider to Python community, but like everyone else, downstream of it, and always affected by it, ever since Python became the de-facto standard in Linux as the language between C and Bash. [1] - Anyone remembers libuv? Spearheading the whole async/await paradigm by powering it in Node.JS, it's one of the most known and talked about libraries ever.

dist-epoch 2y ago
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.
hobofan 2y ago
It doesn't feel too surprising to me. The core developer tooling for Python was (/is) about on par with some of the other top languages (C, C++, Java), but lacking when compared to some of the others (Rust, Go, JS/TS). There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. So it feels like there wasn't any magic, trickery or "take over", but they just filled a void. Control over uv and ruff (and now also python-build-standalone) doesn't really give Astral significant leverage over Python as a language. They are also quite involved in standardizing many parts of uv via PEPs, which I'm sure the PSF could shoot down if they were overly favoring uv's goals. Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence). I think that makes it very hard to compare to e.g. when Yarn entered the Node.js package manager scene. It also doesn't feel too surprising that there is little resistance against commercial involvement. Commercially-led programming languages were quite the norm in the past and also seem to be having a comeback (or trying to). In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not.
- zahlman 2y ago
  >There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. In my book, this happened partly because of disagreement over what tasks the tooling actually needs to do (and because users' needs differ wildly), and a bit because of slow discussions around standards and development of those standards - but mostly because of a poor foundation. It's not that Uv's installer is doing amazing things; it's more that Pip is just badly designed. The internals aren't well factored; it vendors a whole bunch of stuff; it can't offer a usable UI for its own download cache; it doesn't offer an API (and explicitly counsels people to run it in a subprocess); it's designed around the assumption that it will get copied into every virtual environment (even though you don't have to do that any more - except that people don't know this, and it could break if your programs are doing that subprocess trick, unless they declared Pip as a dependency explicitly because who does that?)... the list goes on and on. > Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence) Python has been around much longer than programmers have been talking about "software ecosystems" in the contemporary sense. Pip isn't in the standard library, so that it can be developed and versioned separately. Making the experience smooth (to the extent that it is) requires special-case support in the form of the `ensurepip` bootstrap and `venv` special-casing Pip (for a while, Setuptools got the same treatment). There is an extremely strong insistence in that community on making sure not to break older workflows - as much as people perceive them to get broken all the time anyway. All manner of improvements are held back because we still need to support projects that use `setup.py` exclusively and do so in a variety of legacy ways; and because Python still has to work if you don't set up a "project" at all; and shebangs have to work which has implications for how `sys.path` is initialized, etc. The last time there was a concerted attempt to break everything in order to rebuild it properly, users ended up getting 11 years to adapt to 3.x (9, if you account for 3.0 and 3.1 having serious issues and going back on a decision about how to migrate bytes and unicode literals) and in some cases are still grumbling almost 5 more years past the nominal deadline. >In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not. The developers who have been around the longest seem to have more of that background. The best-known names among the relative newcomers all seem to be people working at large tech companies.
zanie 2y ago
As a pretty minor note, it's not that we _needed_ a two letter name. We considered hundreds of names and it really came down to what was available on PyPI (because it was table stakes that it could be installed from there). We are aware of libuv — it's used in Python too. However, it's a totally different domain and the name conflict isn't really a problem for our users. Frankly, I'm just happy we didn't land on yet another packaging acronym or snake species :)
- wakawaka28 2y ago
  >However, it's a totally different domain and the name conflict isn't really a problem for our users. This is a poor rationalization for violating norms in open source software. No package manager needs to have a name conflict with a popular package or any package for that matter.
toastercat 2y ago
> Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. This happens in the Node/React community literally once or more times a year, haha.

dist-epoch 2y ago

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.

hobofan 2y ago

It doesn't feel too surprising to me. The core developer tooling for Python was (/is) about on par with some of the other top languages (C, C++, Java), but lacking when compared to some of the others (Rust, Go, JS/TS). There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. So it feels like there wasn't any magic, trickery or "take over", but they just filled a void. Control over uv and ruff (and now also python-build-standalone) doesn't really give Astral significant leverage over Python as a language. They are also quite involved in standardizing many parts of uv via PEPs, which I'm sure the PSF could shoot down if they were overly favoring uv's goals. Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence). I think that makes it very hard to compare to e.g. when Yarn entered the Node.js package manager scene. It also doesn't feel too surprising that there is little resistance against commercial involvement. Commercially-led programming languages were quite the norm in the past and also seem to be having a comeback (or trying to). In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not.

zahlman 2y ago
>There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. In my book, this happened partly because of disagreement over what tasks the tooling actually needs to do (and because users' needs differ wildly), and a bit because of slow discussions around standards and development of those standards - but mostly because of a poor foundation. It's not that Uv's installer is doing amazing things; it's more that Pip is just badly designed. The internals aren't well factored; it vendors a whole bunch of stuff; it can't offer a usable UI for its own download cache; it doesn't offer an API (and explicitly counsels people to run it in a subprocess); it's designed around the assumption that it will get copied into every virtual environment (even though you don't have to do that any more - except that people don't know this, and it could break if your programs are doing that subprocess trick, unless they declared Pip as a dependency explicitly because who does that?)... the list goes on and on. > Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence) Python has been around much longer than programmers have been talking about "software ecosystems" in the contemporary sense. Pip isn't in the standard library, so that it can be developed and versioned separately. Making the experience smooth (to the extent that it is) requires special-case support in the form of the `ensurepip` bootstrap and `venv` special-casing Pip (for a while, Setuptools got the same treatment). There is an extremely strong insistence in that community on making sure not to break older workflows - as much as people perceive them to get broken all the time anyway. All manner of improvements are held back because we still need to support projects that use `setup.py` exclusively and do so in a variety of legacy ways; and because Python still has to work if you don't set up a "project" at all; and shebangs have to work which has implications for how `sys.path` is initialized, etc. The last time there was a concerted attempt to break everything in order to rebuild it properly, users ended up getting 11 years to adapt to 3.x (9, if you account for 3.0 and 3.1 having serious issues and going back on a decision about how to migrate bytes and unicode literals) and in some cases are still grumbling almost 5 more years past the nominal deadline. >In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not. The developers who have been around the longest seem to have more of that background. The best-known names among the relative newcomers all seem to be people working at large tech companies.

zanie 2y ago

As a pretty minor note, it's not that we _needed_ a two letter name. We considered hundreds of names and it really came down to what was available on PyPI (because it was table stakes that it could be installed from there). We are aware of libuv — it's used in Python too. However, it's a totally different domain and the name conflict isn't really a problem for our users. Frankly, I'm just happy we didn't land on yet another packaging acronym or snake species :)

wakawaka28 2y ago
>However, it's a totally different domain and the name conflict isn't really a problem for our users. This is a poor rationalization for violating norms in open source software. No package manager needs to have a name conflict with a popular package or any package for that matter.

toastercat 2y ago

> Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. This happens in the Node/React community literally once or more times a year, haha.