> By every other measure it’s been more hostile than average.
I'm not sure there's a "just" here: compared to peer countries, the US is either middle-of-the-pack[1] or significantly more accepting of immigrants[2] depending on which number you pick.
(This isn't to somehow imply that the US isn't hostile to its immigrants, because it is. But the question is whether it's more hostile.)
The parent post says it’s the high economic activity that attracted people even though the US has been more hostile than average by every other measure.
So it's as if the US was a honeypot with a flyswatter.
By the way, your [2] is useless to prove your point: you can't compare absolute numbers (for instance Iceland vs the US).
I don’t think I agree that it’s hostile by every other measure. The US’s immigration system is cruel and capricious, but assimilating into the US seems to be a lot easier than, for example, France or Germany. The US is unusual among its peer countries in not requiring immigrants to speak the “official” language fluently, in accepting public displays of ethnic or religious background that aren’t ambiently European Christian, etc.
(Again, I must emphasize that this does not make the US good. Only that the bar is perhaps lower than people who are assimilated into any particular country may realize.)
I would suggest that the proper metric is not the number of immigrants, which after all the parent commentator implied would be the case because of higher economics drawing them in, but a combination of the following
1. the amount of violence directed against immigrants legally allowed in by governmental forces.
2. the chance of legally allowed in immigrants will have immigration status changed without due process.
3. what percentage of Immigrants fear that 1 or 2 will happen to them.
I believe these two conditions seem to exist in the United States currently, although not sure how many immigrants it affects.
I am unsure if there are other countries that have a similar situation, I would expect if there are they must be relatively few in number.
The closest type of situation would be, I suppose, racial oppression focused on particular groups that have become undesirable according to a country's government.
I think you want `uv tool install` and `uv tool upgrade` for that. But also: please file an issue, because it sounds like the kind of papercut we could address somewhat easily!
I was thinking the same. Furthermore you have the `-e` flag which lets you install the tool in editable mode, meaning that they are run directly and thus any edit you make will be present when you use the tool.
The only thing that you need to be aware of is that if you add another package or change it's version you need to reinstall the tool. I would suggest first removing it with
`uv tool uninstall $NAME` and then reinstall it.
Much of this is useful feedback, even if phrased in a clickbait style. Some thoughts:
- Re: `pnpm outdated`: this is something that hasn't come up very much, even though it seems reasonable to me. I suspect this comes down to cultural differences between Python and JavaScript -- I can't think of a time when I've cared about whether my Python dependencies were outdated, so long as they weren't vulnerable or broken. By contrast, it appears to be somewhat common in the JavaScript ecosystem to upgrade opportunistically. I don't think this is bad per se, but seems to me like a good demonstration of discontinuous intuitions around what's valuable to surface in a CLI between very large programming communities.
- As Armin notes[1], uv's upper bound behavior is intentional (and is a functional necessity of how Python resolution works at large). This is a tradeoff Python makes versus other languages, but I frankly think it's a good one: I like having one copy of each dependency in my tree, and knowing that _all_ of my interdependent requirements resolve to it.
- `uv lock --upgrade` is written like that because it upgrades the lockfile, not the user's own requirements. By contrast, `pnpm update` appears to update the user's own requirements (in package.json). I can see why this is confusing, but I think it's strictly more precise to place under `uv lock`; otherwise, we'd have users with competing intuitions confused about why `uv upgrade` doesn't do their idea of what an upgrade is. Still, it's certainly something we could surface more cleanly, and there's been clear user demand for a uv subcommand that also upgrades the requirements directly.
Agree with you on outdated and upper bounds. However, if users are complaining about the interface being difficult, there is probably something there.
Yes, it makes sense that `uv lock` commands only work the lock file, but users have real needs to upgrade direct and transitive dependencies. For transitive dependencies `uv lock --upgrade-package` works, even if a bit wordy. For direct dependencies, `uv lock --upgrade-package` also works, but doesn't touch `pyproject.toml`, which is much more developer visible. As `uv.lock` package versions get ahead of `pyproject.toml`, `pyproject.toml` becomes a less dependable guide to the surface area of dependencies. A friendly `uv upgrade` command would be nice.
The biggest uv ux footgun I have seen by far is `uv pip`. I have seen a lot of projects use uv correctly with pyproject.toml/uv.lock for development, but then use `uv pip install -r pyproject.toml`, which bypasses uv.lock, in their deployment Dockerfiles and ci tooling. Yes, coding agents are to blame for recommending bad `uv pip` patterns because they have so much `pip` in their training sets, but uv should provide some affordances to protect the user.
Sorry for the rant, uv is a great tool, that I think[0] should be used more! Thank you for your contributions to the ecosystem.
Author of the article here. Sorry it comes across as “clickbait style” when actually it’s simply Dutch bluntness and honesty
poetry update also updates the lockfile. I really think the way the uv cli is organized makes it quite annoying to work with. It’s designed for correctness, for machines, not for user-friendliness.
Not having used uv but being on the Cargo team for Rust, I wish `cargo update` was `cargo lock update` because it is making our life more difficult to add a version requirement update command/mode inside of Cargo. The effort has been stalled for years.
- Our compatibility guarantees mean we can't fundamentally change `cargo update`
- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two
- We have to be very careful adding the mode to the existing command
fwiw `uv upgrade` is on the roadmap — we just haven't done it yet because it's hard to build a great experience for it (there are far more nuances than people expect) and we're a small team with a lot of priorities.
> `pnpm outdated`: this is something that hasn't come up very much, even though it seems reasonable to me.
One use for it is to see what would be updated by running "uv sync --update" or "uv lock --update". Although that might be better served by having a confirmation prompt for those commands.
Well, I think the ideal would be to default to prompting, but have a "--yes" or "--non-interactive" option to turn it off in CI and similar, but that might be problematic for backwards compatibility now, but an "--interactive" or "--prompt" flag now would be better than nothing. Especially, if you can configure that in ~/.config/uv/uv.toml
The analogy in npm is dependency proliferation, along with what appears to be weaker community norms around security. To the extent that either or both of these are true, I think the “no way to prevent this” quip is essentially accurate.
Exfiltrating an admin token is a big "if"; you shouldn't issue admin tokens at all, and GitHub does (at least for me) pop a proper MFA challenge when attempting to issue one.
(I wrote that Astral post.)
Edit: separately, I'll note that the risk of long-lived, highly privileged credentials is the primary motivating reason for Trusted Publishing: a developer's machine has (by necessity) a much higher degree of access than an ephemeral runner does, making it a much juicier target for an attacker. It also runs all kinds of stuff in a mostly unsandboxed manner, making it easier (in principle) to exploit. That's not to say there shouldn't be additional guards on publishing, but that I'm not remotely convinced that local publishing is any better by default.
Not to belabor the point, but LF is a 501(c)(6), not a 501(c)(3). They don't behave like your intuition for a public-interest nonprofit because they aren't one. You shouldn't give them your money!
It's an industry trade association, for the benefit of its members. You aren't one of its members. (I'd suggest spending 60 seconds researching the difference between a 501(c)(3) and 501(c)(6) on wikipedia or whatever.)
I have, maybe you should too. Other than stating it’s not a 501c3, I haven’t heard a compelling argument. I think it’s OK that Linus gets paid to do what he does. Everyone here definitely benefits from this non profit organization. It’s ok we see it differently.
Is it? Percentage-wise, executive compensation appears to be lower than well-regarded technology nonprofits[1][2]. In some sense that's extremely weird, since LF is a trade organization rather than a public-interest nonprofit. Their financiers are huge corporations, not individual donors!
(This is the core of the bigger problem with LF, IMO -- they simply don't represent non-corporate OSS interests at all, beyond some lip service.)
Without bending over backwards to defend the Linux Foundation, I'll point out that the 97% number means very little -- the percentage that actually matters is the percentage that doesn't go towards funding open source at all. The Linux Foundation hasn't been solely about Linux for decades; they are (facially) responsible for hosting a very large number of open source projects.
And one would argue without actually focusing on Linux the kernel and Linux distro on top for the average user, they're just funding server FOSS for use by fat companies
That’s explicitly their mission, though! They’re a trade organization that advances member interests, not a public interest nonprofit.
(In effect, they’re a coordinating body for fat companies. They do indeed fund things in those companies’ interests, but they do it with corporate money.)
>They’re a trade organization that advances member interests, not a public interest nonprofit.
Maybe they should say that with a huge banner on their website then. How many people give them money thinking it's for the good of FOSS in the idealistic sense?
Very few, I think. I had to search for their “donate” page, and it says explicitly that donations are not tax deductible.
(FWICT, the overwhelming majority of LF’s money comes from conference fees, and the biggest chunk of the rest comes from corporate dues. Private donations don’t appear to be a significant portion of their income.)
I'm not sure there's a "just" here: compared to peer countries, the US is either middle-of-the-pack[1] or significantly more accepting of immigrants[2] depending on which number you pick.
(This isn't to somehow imply that the US isn't hostile to its immigrants, because it is. But the question is whether it's more hostile.)
[1]: https://www.visualcapitalist.com/charted-the-share-of-foreig...
[2]: https://www.oecd.org/en/data/indicators/stocks-of-foreign-bo...
reply