charliermarsh

6 ms·

1.
by charliermarsh 17d ago
Making things faster is much easier than making things smaller. I'm sure we can win back a 4% slowdown elsewhere since we have so many more levers to pull from.
2.
by charliermarsh 2mo ago
These are the Python distributions we use in uv ( https://github.com/astral-sh/uv ), i.e., when you install Python with uv, you're installing from python-build-standalone. (Same goes for many of the other tools that
3.
by charliermarsh 9mo ago
> Man, it's easy to be fast when you're wrong. But of course it is fast because Rust not because it just skips the hard parts of dependency constraint solving and hopes people don't notice. We ignore upper bounds because i
4.
by charliermarsh 9mo ago
I'm not super familiar with Bundler's architecture but I think the most impactful thing would be adopting uv's cache design, which is a big part of what makes uv so fast and should be replicable in other languages and ecosyst
5.
by charliermarsh 9mo ago
If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.
6.
by charliermarsh 11mo ago
We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!
7.
by charliermarsh 1y ago
The PEP includes the ability to enable (or disable) lazy imports globally via a command-line flag or environment variable, in addition to the import syntax.
8.
by charliermarsh 1y ago
Lazy imports have been proposed before, and were rejected most recently back in 2022: https://discuss.python.org/t/pep-690-lazy-imports-again/1966... . If I recall correctly, lazy imports are a feature supported in
9.
by charliermarsh 1y ago
All of our tools can be used independently and in coexistence with other tools. You can use `uv` with other build backends; you can use `virtualenv` to create your virtual environments, and `uv pip` to install into them; you can use `ruff`
10.
by charliermarsh 1y ago
We already develop a formatter: Ruff ( https://github.com/astral-sh/ruff ). Ruff and uv are built by the same team. `uv format` is just an optional front-end to `ruff format`.
11.
by charliermarsh 1y ago
`uv format` is just a front-end for `ruff format`. It isn't introducing a new formatter to the ecosystem or anything like that.
12.
by charliermarsh 1y ago
Yeah, you can definitely use `uvx ruff` (an alias for `uv tool run ruff`) to invoke Ruff. That's what I've done in my own projects historically. The goal here is to see if users like a more streamlined experience with an opinionat
13.
by charliermarsh 1y ago
It's a separate binary -- we install Ruff if you invoke `uv format`. So if you don't invoke `uv format`, there's no impact on the binary size, etc.
14.
by charliermarsh 1y ago
Good questions. I don't think we'd ever deprecate Ruff because `uv format` exists, and adding `uv format` won't have any impact on Ruff's release cycles or development. The analogy would be to Cargo: `cargo fmt` just run
15.
by charliermarsh 1y ago
To clarify, `ruff` and `uv` aren't being merged. They remain separate tools. This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool. The analogy would be to Ca
16.
by charliermarsh 1y ago
> Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx? We actually support this basic idea today, even without pyx. You can run (e.g.) `uv pip install --torch-backend=auto torch` to auto
17.
New usage limits for Claude Code(twitter.com)
4 points by charliermarsh 1y ago|1 comments
18.
by charliermarsh 1y ago
uv works just as well with whatever Python you want to bring -- you're not required to use the Pythons that uv is capable of installing on your machine.
19.
Using uv with PyTorch(docs.astral.sh)
170 points by charliermarsh 2y ago|54 comments
20.
by charliermarsh 2y ago
The piece of this apology that I have trouble understanding is this: > We thought the license in the root repo wasn’t that important, so we just generated one that we thought was open. The root repo already had an Apache license in it. I
21.
by charliermarsh 2y ago
We didn't support those workflows until today. If you'd prefer a true diff: uv adds support for projects, cross-platform lockfiles, scripts, and Python installs
22.
by charliermarsh 2y ago
Thanks dang, I appreciate it. I'd suggest something like: uv: A unified alternative to Poetry, pipx, pyenv, and more
23.
by charliermarsh 2y ago
I wrote about it a bit here: https://github.com/astral-sh/rye/discussions/1342
24.
by charliermarsh 2y ago
Was this section removed? I'm not seeing it in the linked post.
25.
by charliermarsh 2y ago
Yeah, that's definitely within scope for what we're trying to build, and we've been hard at work on extending uv to support those workflows (platform-agnostic resolution, lockfiles, etc.). Honestly, a lot of it is already imp
26.
by charliermarsh 2y ago
(Thank you for this, it was really inspiring for me to read.)
27.
The Missing Parts in Cargo(weihanglo.tw)
3 points by charliermarsh 2y ago|0 comments
28.
by charliermarsh 2y ago
Yeah that's right -- we make the assumption that all distributions for a given package will yield the same dependencies, similar to Poetry, PDM, and other tools. This is not strictly required by the standards, but it's very rare f
29.
by charliermarsh 2y ago
A lot of our core packaging development is now happening in uv [1]. Rye uses uv under the hood, so as we improve uv, Rye gets better too. E.g., we recently added support for "universal" resolution in uv, so you can generate a lock
30.
by charliermarsh 2y ago
This is a very nice article, thank you for the kind words.

More ›