Yeah, my point is just that other package managers aren't in a great spot. NPM even lets you separate out "publish" and "release" now where you can publish to the registry but you have to separately "ack" that to release. That's kinda a huge win if people use it.
I just think the framing that npm is so bad is really flatly invalid.
I don’t think npm itself is measurably bad in ways that are useful to index on. Like others, I think that JS as an ecosystem has a culture that encourages both dependency sprawl and living at the edge, both of which contribute to the end problem of OSS malware.
(Rust has a similar culture, to be clear. I don’t think it’s a death knell.)
Defense in depth is the “meat and potatoes” of security.
In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.
Defence in depth is not just 'throw anything in that might improve security' though. The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed. A stronger layer might be sandboxing, or separating your build and publishing steps as others have suggested (and also probably worth restricting the credentials the publishing step to just the relevant packages as well). These will at least robustly prevent a malicious dependency from spreading horizontally, but you'll still potentially ship malware to your customers.
>The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed
Definitely. On the other hand, in my opinion, "not running arbitrary code during package install" is not a "half-measure", it's a basic sanity. This whole arbitrary code execution at install time is a convenience feature that was adapted by some package managers, but it was never a good idea.
Fortunately, nixos solves that for me in most cases.
doesn't nixos still have execution hooks when you actually activate a package to use it? Arguably it's just separating the download and install steps (which I do agree, every package manager should have a 'safely download this package so I can inspect it' function as well as a 'make this package ready to use' function, whatever you call those operations. I think 'pip download', for example, managed to violate that expectation which is not particularly sensible)
You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking.
(On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my development bottleneck.)
cargo check is useful to verify the code compiles (it's extremely rare to have compilation errors that survive cargo check). But cargo build is required if you want to actually try out the code you wrote, e.g. in order to run a test that you or the LLM wrote.
Yeah but like, tests encode behavior… sometimes I go all day without running a test. Sometimes multiple days. I’ve been using unit tests less and debug asserts more and more now days anyways. Encoding behavior as close the relevant code as possible. And using types and type state to minimize invariants. Idk, but it seems like such a smell when my coding agent drops 10 unit tests for a 300 LoC module. It means it did a bad job of writing the code in the first place.
Anyways, if the code compiles, but the behavior is wrong, a test might be useful. But so is reading the code… so I’m skeptical of rerunning tests constantly.
Yeah, I mean more for the iteration half -- YMMV, but I find that I make the LLMs most productive when I have them design the typestates first, ensure they compile, and then work on tests after that (rather than stacking tests through the process).
A non starter for anything related to graphics or UI development, which is kind of most Rust stuff are CLIs or TUIs, like being back on curses heyday, Turbo Vision and Clipper.
Is it? An immense amount of the world’s graphical software is written for native graphical targets like SwiftUI, where the iteration cycle is similarly bound to build times. It’s certainly painful, but I don’t think it’s a non-starter.
Rust has an incremental compiler. And TMU SwiftUI’s live preview is essentially a very rough approximation of what the actual build would produce; it’s not a suitable replacement for a real build when developing a non-trivial UI.
My rust compiles in the time it takes to switch from my editor to my browser to see the changes incremental recompiles are fast enough imo. Dioxus has hot reloading if you want to go faster and Bevy uses it for hot reloading as well.
Gamedevs usually have the most powerful machines of all types of devs because of it's very nature. Yes you can't compile Rust on the GPU but big gpu's come with big CPUs usually.
Anecdotally: I disabled Zed’s AI features, but I use LLMs more extensively than ever outside of my IDE. So the numbers may not paint a clear story here.
I don’t think that’s a parsimonious explanation in a post-COVID world. It seems equally if not more likely that talent is more distributed, and people find fewer reasons to relocate into the Bay Area (in terms of career progression, etc.)
(This is not, in my mind, either a good or a bad thing.)
Maybe a naive question, but any goal / progress towards an ”it just works” cuda installation? Currently, the only times i feel like i‘m stumbling over an install with uv is when pytorch / cuda is involved.
Pixi is very focused on the Conda ecosystem and implements a sort of bridge across the Conda and PyPI ecosystems. I am very interested in solving the problems that motivated creation of the Conda ecosystem, but I want to do so by driving forward the PyPI ecosystem so those use-cases can be addressed in _many_ tools instead of just one. This is the main reason you don't see us pursuing Conda package support in uv directly (in the style of Pixi).
There have been several threads about us collaborating or converging, but there are no concrete plans to do so at this time. We share some Rust crates, e.g., Pixi uses our internals to solve the PyPI-side of their dependencies, and we occasionally fix or change things for each other.
We have the interface because we care a lot about meeting people where they are.
We keep the interface because we care a lot about long-term support and compatibility. I cannot imagine removing it.
We generally want to add features to the top-level interface such that people don't need or want to use the pip-interface because the top-level interface does everything you need, but better.
Laudable goals. Have you considered gating imperative commands behind a setting, maybe `tool.uv.pip.unreproducible = true` or somesuch? This would gently guide people towards better workflows, and also be a starting point for documenting the drawbacks of `uv pip` since it's a setting they'd be forced to add and presumably they'll read the docs for it first.
uv already does something similar with `tool.uv.pip.break-system-packages`.
FWIW, break-system-packages comes directly from pip's interface, it's not a novel addition from uv.
If Astral/OpenAI are willing to support uv pip in the long term, why do you think they should use a stick as well as a carrot to get people on uv's top level interface?
While uv's standard workflows probably works for 80+% of people, at least if they learn them, I certain do a lot of stuff with uv pip and pip that can't be replicated.
Also both uv pip and pip support installing from pylock.toml files, which are fully reproducible.
I hadn't considered that, it's an interesting idea. We generally hold a very high bar for nagging users or gating behaviors. It's possible we'll reach a point someday where this is appropriate! I think you're right that we need to teach people better workflows, but that's happening organically as use of the tool grows and people's first exposure to a Python project is `uv init` and `uv add` rather than `pip`.
Fair points; the reason for asking is that it seems counterintuitive from the outside perspective for you to maintain/extend the pip interface as well?
And of course that some colleagues of mine insist on using `uv pip` for anything and everything, which feels wrong…
Granted it’s a great feature which made the transition to uv smooth in the first place.
So far the maintenance burden has been quite bearable and extending pip provides us with an opportunity to explore and encourage improvements upstream which are still beneficial to a lot of people.
It’s widely used, and there are still a lot of workflows that we hear about from users where they want/need to manually twiddle environments rather than having the “declarative” layer do it for them.
Agreed, I'd prefer it stick around for the long-term because I use it when creating temporary venvs to screw around with things that I'm not certain about committing to in my actual projects for example. I guess I could do that with scripts but it's nicer/easier to use uv pip
Bit surprised, and disappointed to not see dynamic field support for the uv build backend in this update. Need it for dynamically getting the version from Git. Is there anything blocking it, or is it just not important enough?
Unfortunately dynamic metadata is not efficient for package resolution, so we don't want to encourage it. Instead, we want to design a better workflow for using source control for versioning, but haven't had the time to do so.
Interesting, a better way of doing versioning would be nice. The tool I use requires a git repo setup with at least 1 commit, annoying for brand new projects. I'll be eagerly waiting to see it eventually.
At what point is that the case? When a package is built, it's version is determined at that moment from whatever dynamic source, and is then written into the metadata in a static way (or surely could be if for some weird reason it isn't).
WDYM by madness? I know what the flag is (and what it does), but people have strong opinions in opposite directions about what Python packaging should do around system environments.
We want to support that workflow / experience but we want to design it differently because there are a lot of nuances to pip's interface and the pip maintainers have encouraged us to rethink it.
It's also non-trivial to implement because of how our cache design differs from pip's.
(I have no opinion about the overall security posture of these indices.)
reply