&gt; uvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades.Couldn&#x27;t the user just run `uv tool upgrade &lt;tool_name&gt;`?

UV has done so much for Python but I did fight it a bit today.I was trying to centralize the management of a script that appears in a few different repos, and has invariably drifted in its implementation in multiple way over time.My idea wasuv run --with $package main --helpI was looking for an easy way to automatically1. Install it if it doesn’t exist and run
2. Don’t install it if it’s running the latest version
3. Update if it’s not on the latest versionAll three were surprisingly tricky to accomplish.By default uv run will reinstall it every time. Which is 6 seconds of venv and installsuvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades.I ended up having the script run a paginated GET on codeartifact and update if there’s a newer non-dev version (and then re-execute).That seems to work. And 200ms delay is better than 6 seconds. But it wasn’t quite the experience I wanted.

Isn&#x27;t there a lock file for that? I&#x27;m mostly a rust dev, but I thought I saw a lock file in a uv project I was vibe coding

But that&#x27;s why you have a lockfile?

That doesn&#x27;t work for library projects, though.

Also it doesn&#x27;t even matter because the real way to use both uv and npm is to switch everything to = and only update manually, rather than trusting non-major updates not to break anything

The use or adherence to semver isn&#x27;t the problem here. As you say, if a package follows semver, it&#x27;s easy enough for the package managers to automatically update to newer compatible versions. The problem is when you want to have two different incompatible versions of the same package `foo` in the same program, because then you have to figure out what `import foo` means. You might say &quot;just don&#x27;t do that&quot;, but that package could be an indirect dependency of several of your direct dependencies. Some languages handle this natively, e.g. in Rust it just works if you have multiple versions of the same library in different parts of your dependency tree (and you&#x27;ll get a compilation error if you try to pass a type from one version into a function of an incompatible version). But Python does not handle this use case very well.

Semantic versioning is about versioning individual dependencies, no? The issue here seems to be about transitive dependencies, where different versions of the same package is used by multiple packages which depend on it.uv&#x27;s default being to always select the latest version seems to be what Clojure&#x27;s tools.deps does.

There isn&#x27;t a good way to know if a given package is using semver though.There&#x27;s a lot of packages in the Python ecosystem that use time based versioning rather than semver (literally `year.minor`) and closed ranges cause untold problems.

The entire purpose of semver is to give you a way to resolve that conundrum. New major version = assume it&#x27;s incompatible.I mean, it may not actually work, but that&#x27;s what it&#x27;s for.

“It’s tough to make predictions, especially about the future.”--Yogi Berra

&gt; Note the lack of an upper boundSince uv needs a singular resolution that&#x27;s entirely intentional. In npm you can install diverging resolutions for different parts of the tree but that is not an option with Python. I had to make the same decision in Rye and there is just no better solution here.If an upper bound were to be supplied you would end up with trees that can no longer resolve in practice. Some package ecosystems in Python even went as far as publishing overrides for old packages that got published with assumed upper bounds that ended up wrong.Don&#x27;t forget that you cannot know today if your package is going to be compatible or incompatible with a not yet released package.

That phrase and &quot;Who designed this command line interface&quot; are probably written for attention and clicks. The feedback content is useful and I agree with most of it but using such phrases diminishes the value of that feedback and invites defensiveness. I find uv&#x27;s command line interface cumbersome for me too but I understand why it was written this way.

&gt; “is a mess”then cites two examples where you have to write a couple extra args..better title: “QOL changes i wish UV had”

Coming to uv from pip, I fall back to<pre><code> uv pip list --outdated
</code></pre>
when I need that information.

(Note: I work on uv.)Much of this is useful feedback, even if phrased in a clickbait style. Some thoughts:- Re: `pnpm outdated`: this is something that hasn&#x27;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&#x27;t think of a time when I&#x27;ve cared about whether my Python dependencies were outdated, so long as they weren&#x27;t vulnerable or broken. By contrast, it appears to be somewhat common in the JavaScript ecosystem to upgrade opportunistically. I don&#x27;t think this is bad per se, but seems to me like a good demonstration of discontinuous intuitions around what&#x27;s valuable to surface in a CLI between very large programming communities.- As Armin notes[1], uv&#x27;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&#x27;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&#x27;s own requirements. By contrast, `pnpm update` appears to update the user&#x27;s own requirements (in package.json). I can see why this is confusing, but I think it&#x27;s strictly more precise to place under `uv lock`; otherwise, we&#x27;d have users with competing intuitions confused about why `uv upgrade` doesn&#x27;t do their idea of what an upgrade is. Still, it&#x27;s certainly something we could surface more cleanly, and there&#x27;s been clear user demand for a uv subcommand that also upgrades the requirements directly.[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=48230048">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=48230048</a>

Yeah, this is when it really matters that they wrote it in a CPU-performant language. There have been times I pointed uv at a random pip-managed GitHub project to rescue it because the author forgot to specify some versions and entire deps in requirements.txt. It even took uv a bit of chugging to find an overlap. Also wow, those packages had a lot of pointless breaking changes.

uv has a lot of great features, but the dependency resolution is why I&#x27;m a fanboy. It can resolve trees that pip gives up on, and it does it 20x faster than poetry (100x faster than pip) - saves me half an hour on some big projects. All the python resolution and environment management and stuff is just gravy.

Interesting point of view and I think feedback is good. Although I agree with the overall sentiment of the article, I disagree with the intensity of the criticism.Having a command runner within your project will mask a lot of the issues the author mentioned. And although, in my experience, having a command runner for mid-sized projects and up is useful for many things, masking the UX issues means there&#x27;s a problem.I got on the uv bandwagon relatively recently as most of my work is maintaining older python projects so I&#x27;ve been using it for new builds. Although the speed part is welcome, I couldn&#x27;t see what the big deal is and mostly keep on using it because it is a popular tool(there are benefits to that in my line of work) and not necessarily because it can do something that couldn&#x27;t be done before though with a couple of other tools. Whether it is beneficial or detrimental to having all of that functionality within one tool, to me, is a matter of opinion.The problem to me is that I&#x27;ve seen this cycle many times before. New tool shows up claiming it is far superior to everything else with speed being a major factor and everyone else is doing it wrong. Even though the new tool does a fraction of what the old &quot;bad&quot; tool is doing. With adoption comes increased functionality and demands and the new tool starts morphing into the old tool with the same claimed downsides. The UX issues to me are a symptom of that process.I still think uv is a fine tool. I&#x27;ve used poetry before and sometimes plain old pip. They&#x27;re all fine with each tool catering to different use cases, in my opinion. Sometimes you have to add pyenv, sometimes you don&#x27;t. Sometimes you add direnv, sometimes you don&#x27;t and so on. And I&#x27;ve cursed at everyone of them at times. However, the fanboyism is very strong with uv which makes me wonder why.

Uv is fantastic, but its package management UX is a mess

Project Hail Mary – Stellar Navigation Chart

Using Kagi Search with Low Vision

Blog ran on Ubuntu 16.04 for 10 years. I migrated it to FreeBSD

AI is killing the cheap smartphone

Google Is Shattering Under Its Own Weight (The IBM-Ification of Google?)

We're testing new ad formats in Search and expanding our Direct Offers pilot

Was my $48K GPU server worth it?

For the past 5 years or so I&#x27;ve been working on a ground-up redesign of Freenet, my peer-to-peer project from the early 2000s (now renamed Hyphanet).The new Freenet has been up and running since December along with some early applications like River[1], our decentralized group chat and Delta - a decentralized CMS. Users have already started to build their own apps on Freenet including games, and we have some interesting apps in development like Atlas, a search&#x2F;recommendation engine.Architecturally, this new Freenet is a global, decentralized key-value store where keys are webassembly contracts which define what values (aka &quot;state&quot;) are valid for that key, how or when the values can be mutated, and how the state can be efficiently synchronized between peers.We&#x27;ve developed a unique (AFAIK) solution to the consistency problem, every contract must define a &quot;merge&quot; operation for the contract&#x27;s associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you&#x27;ll get the same end result.This approach allows state updates to spread through the network like a virus[2], which typically achieves consistent global state in a few seconds or less.Like the world wide web, Freenet applications can be downloaded from the network itself and run in a web browser - similar to single-page apps on the normal web. However, rather than connecting back to an API running in a datacenter, the webapp connects locally to the Freenet peer and interacts with Freenet contracts and delegates over a local websocket connection.If you&#x27;d like to try Freenet we have convenient installers for the major desktop OSs but not yet mobile, and you can be chatting with other users on River within seconds[3]. Happy to answer any questions, you&#x27;re also welcome to read our FAQ[4], or watch a talk I gave back in March[5].[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;freenet&#x2F;river" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;freenet&#x2F;river</a>[2] <a href="https:&#x2F;&#x2F;freenet.org&#x2F;about&#x2F;news&#x2F;summary-delta-sync&#x2F;" rel="nofollow">https:&#x2F;&#x2F;freenet.org&#x2F;about&#x2F;news&#x2F;summary-delta-sync&#x2F;</a>[3] <a href="https:&#x2F;&#x2F;freenet.org&#x2F;quickstart&#x2F;" rel="nofollow">https:&#x2F;&#x2F;freenet.org&#x2F;quickstart&#x2F;</a>[4] <a href="https:&#x2F;&#x2F;freenet.org&#x2F;faq&#x2F;" rel="nofollow">https:&#x2F;&#x2F;freenet.org&#x2F;faq&#x2F;</a>[5] <a href="https:&#x2F;&#x2F;youtu.be&#x2F;3SxNBz1VTE0" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;3SxNBz1VTE0</a>

Show HN: Freenet, a peer-to-peer platform for decentralized apps

Indexing a year of video locally on a 2021 MacBook with Gemma4-31B (50GB swap)

Spotify will start reserving concert tickets for fans

Python 3.15: features that didn't make the headlines

Hey HN, We&#x27;re Gus and Carlos from Runtime (<a href="https:&#x2F;&#x2F;runtm.com">https:&#x2F;&#x2F;runtm.com</a>). We&#x27;re building infra that lets your whole team (including non-engineers) ship with Claude Code, Codex, and other agents without engineering having to handhold every session.After Mentum (YC S21) was acquired, I personally shipped 4 full-stack products in 3 months using coding agents. When I tried to roll the same workflow out to the rest of the team, it fell apart: Most PRs were unmergeable slop - Every repo required an engineer doing one-off local setup. - Skills and context lived in one person&#x27;s head. - There was no safe way for a PM to touch a real codebase without risking a bad deploy or a secrets leak.Carlos comes from building agentic reconciliation systems at Modern Treasury and had a similar experience when letting his support team use devin.We ended up building internal background agent infra but it quickly became a nightmare to mantain and develop. We built Runtime so you don&#x27;t have to do this kind of thing.Runtime work like as follows. Engineering defines the context once: system instructions, skills, and scoped integrations installable via CLI, mise, npm, or any package manager. Then Runtime snapshots your full running environment including multi-service Docker Compose setups, Kafka, Redis, seeded DBs, so it comes up in milliseconds with every server already running.We orchestrate across sandbox providers like E2B, Daytona, EC2 or self-hosted K8s depending on your setup. Secrets are injected through our managed proxy so they never touch the agent directly, and guardrails run at the infrastructure level: command allow&#x2F;deny lists, network egress controls, and RBAC scoped per human and per agent. Every session also gets a shareable preview URL, so internal builds go from sandbox to the rest of the team without needing production access.Runtime works with whichever agent your team already uses: Claude Code, Codex, Cursor, Copilot, Gemini, Devin. You can trigger sandboxes from our web app, CLI, Slack, Linear, GitHub, or API.One of our customers built an on-call inspector that wires PagerDuty, Sentry, and their repo so when an alert fires, the agent finds the cause and opens a PR with a unit test before anyone gets paged. Another runs a finance agent in a private Slack channel pulling from Stripe, NetSuite, and Snowflake to run reconciliations in minutes with source rows attached.A fintech unicorn and several YC scaleups are live on Runtime, including a few teams who had built similar infrastructure internally and handed it to us to take over.The core is open source at <a href="https:&#x2F;&#x2F;github.com&#x2F;runtm-ai&#x2F;runtm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;runtm-ai&#x2F;runtm</a>. Hosted version is live at <a href="https:&#x2F;&#x2F;app.runtm.com">https:&#x2F;&#x2F;app.runtm.com</a>, free tier included. We&#x27;re charging a flat platform fee plus compute, no token markup.Check our demo: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=wLwj__aEEh4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=wLwj__aEEh4</a>We&#x27;d love to hear how you&#x27;re thinking about the infra for letting more people across your org use coding agents without creating chaos!