Видео

Thank you; you and I both! 😅

sadly I can't, because I've bounced of NixOS many times. However, I've already heard from Nix friends that they plan on creating something like poetry2nix for uv's - and hopefully eventually Python's official - lock file format.

Conda has a very different scope than Python's packaging - it's closer to a Linux distribution than to an ecosystem packaging solution.

Which is why it's now time to celebrate! 🥳

Sorry, I don’t know anything about Mojo beyond that it exists and that it‘s from Chris Lattner.

Where: `uv python dir` How to prevent: `UV_PYTHON_DOWNLOADS=never ` How does it integrate: it doesn't, that's the whole point. People have been begging for a decoupling forever. If you don't want that, the the env variable or pass `--no-python-downloads`. I set the variable in all my Docker base images.

There's also configuration files at a project, user and (soon!) system level where you can configure this too.

I'm trying my best to follow the rough rule that I don't speak ill of other people's projects which has the unfortunate but inevitable consequence that I'll never speak about Poetry.

If you need concrete help, I recommend dropping by Astral's Discord; people there tend to be very helpful discord.com/invite/c9MhzV8aU5

thank you, thank you, thank you! 😊

I still occasionally do `uvx run CMD` 😬 Supplanting Rye is a major goal, so only a matter of time.

I'm very glad to hear it did its purpose! The first video should probably have been two, but I suspect the uv angle lured more people in than if it were just about the packaging part. :)

name of the vid, i hav exact same need

Thank you for finding and appreciating my backcatalog! That video specifically is very dear to my heart. :)

Nuitka is a Python to C++ compiler, that's something different entirely. uv is only about packaging Python code and an alternative to Pip (since last video) and/or PDM/Poetry/Rye (since this video).

thank you Michael - always great to hear from you! 💜

Thank you! And you and I both hope the same thing ;)

Thank you! 💛 `uv tools` and `uvx` are tools that you don't use with your own project (that would be `uv run`). They are the replacement for `pipx`: so if you have Python tools that you want to use outside of projects, it manages virtualenvs (and Python versions) for you. For example `uvx --from httpie http httpbin.org/json` or `uv tool install --with tox-uv tox` (and then you can run `tox` in your shell whereever you are).

@@The_Hynek would love migration video .. i think this fit with most people as a challenging usage while uv init to start a new project is the easiest to do

The problem with migration videos is "migrate from WHAT?" - one of the problems uv is solving is that currently there's virtually an infinite amount of workflows.

Until 0.3.0, it was all speed (see my older video - there's a lot more context). Now, most of what uv adds is comfort and misuse safety. As I say in the video: you can give a project to a total newb and they can run `uv run pytest` and uv takes care of EVERYTHING. They can git pull some updates that update dependencies and `uv run` again, and uv will make sure all updates are applied. This eliminates a lot of problems that plagued teams before. Finally, to borrow my own words: the cross platform lock file is the crown jewel of post-0.3.0 uv. It's a HUGE deal if you need to develop across architectures like I do (ARM vs Intel) or across operating systems (macOS vs Linux vs Windows). This works for .txt lock files only when the dependencies are exactly the same, which they often aren't. For this you used to have to use PDM and Poetry that come with their own sets of problems.

@@The_Hynek thanks!!!

@@The_Hynek so does uv run do uv sync first then actually run?

For all intents and purposes, yes. If you always use `uv run`, any changes to uv.lock (e.g., a git pull) are applied automatically

​@@The_Hynek that's nice. I didn't realize that it joins a lot of tools together into a single one, included automatic git pulls and so on. It greatly simplifies the workflow.

We have to see things in relation to the reality that we live in. Yes, there’s the heat end of universe. And yes, Go programs compiled on Jammy don’t work on Focal. But relative to the CURRENT jankiness of existing tools, it‘s IMHO fair to use the mild hyperbole of "never".

There is a bit of history to this angst in the Python community: large parts used to be written in C and we worked for many years to port them to Python, if possible. Making it more approachable and maintainable. That’s how the Mastodon thread starts, in fact. Starting to add Rust is a step back in that sense, but IMO that isn’t really comparable. But it certainly does feel so for some.

I cannot speak for Astral, but they’re maintaining both right now and made it clear that uv wi take over eventually: github.com/astral-sh/rye/discussions/1342 but not until its “better”: github.com/astral-sh/rye/discussions/1164 Since I don’t use Rye myself, I cannot weigh in on it usefully.

Same! I fell in love with it last year just to get it ripped away again. :(

I cannot open-source our work repositories, but I promise I'll make a video once it's possible to use uv's project workflows for open-source projects (that aren't applications for Docker deployments etc).

Well, this is obviously a trade-off question and even more so a question of trust and incentives. So far, Astral hasn't broken anything they've officially shipped for me and given they want to be a viable alternative, I suspect they're gonna do their best to leave it that way. It's also not like other packaging tools never break. But again, there's no definitive answer but I can say for myself that the only things I had to change in my uv usage was the removal of work-arounds.

Do you even know what you talking about? It's good to have options, so we can choose the best one for the use-case. Npm, pnpm, bun and yarn are all pretty good at doing their job. Apart from yarn which is now shit since no one knows if we should use v1 or v3 (where is v2? 😂 And v3 is complete shit, but at least they forced npm to improve perf). Diversity brings resilience and quality. Whereas pip is the worst piece of software ever written, everyday failing to install more and more packages for no reason, worst dependency resolution ever, can't give a helpful error message, and slow. And poetry is not using standard Pep 641 for pyproject.toml config + their optional dependency config is garbage. So any alternative is welcome! (Really can't wait to fully see pip go away, this is the worst software I have ever seen, no idea how it stays for so long) Ruff has already solved python formatting and linting (byebye flake and black, happy to forget them). So we can expect the astral team will continue building well designed tools. This space is even already better than JS because eslint is a pain to configure And uv comes packed with ruff. So you literally get npm, eslint, prettier, nvm with uv. All you need is something for static type checking.

I understand this is an emotional topic, but y’all aren’t disagreeing as much as y’all seem to think. I think it’s a good thing that uv is taking lessons from Rust and not JavaScript that is, as you admitted yourself, rather fragmented itself. Not to forget, that the whole npm platform is owned by Microsoft - which I suspect is one of the reasons why people are apprehensive of Astral being a company. We already have an npm-like package manager that I won’t name, because I hate it. “It’s good to have options.” is something we (myself very included) have been saying for years, but the normies disagreed.

This seems like a false dichotomy right there. Devenv, for example, has uv support baked in. You don't have to use all of uv's features to benefit.

Wdym by manually symlinking?? I use pyenv + pyenv-virtualenv. The process of starting a new project is as simple as: 1. Create the venv: `pyenv-virtualenv 3.12.1 my-new-project`, 2. Ensure youre in the directory of your new project and then set it as the venv for the project's directory: `cd /some/path/myproject && pyenv local my-new-project`, and then you're ready to go. There's no manual symlinking required, hence why I'm confused by your comment..

"implements the entire Python interpreter as a rust macro" wat

💛💜

That makes no sens! Just look at the other for profit companies that do open source tooling like redhat... Oh wait

A maintainer burning out is at least just as likely as Astral rug-pulling us. In both cases we as a community have to take over. For instance, there’s essentially no original pip author still on board.

@@The_Hynek I think in many cases I might agree, but for core tooling I would rather have it in the hands of the python community. This would reduce the risk of a rug pull and simplify things going forward if the maintainer wants to retire. In addition to a complete rug-pull where the software is completely closed up, there are other in-between situations we could find ourselves in. Some of these are worse than losing access to new versions because they would split the user base. It is better to have an abandoned project than multiple concurrent forks such as in the case of Redis or Terraform.

I mean I agree in general, the problem is that the community hasn’t produced anything comparable in over a decade of trying. The problem at hand (I talk about it more in my first video) is so much more complex than people realize, especially compared to Rust or JS. Astral is giving us a much-needed speed-bump, until the community has to take over again.

There is no such thing as “Python itself”; there’s only the CPython core team of volunteers and they’ve made clear many times that they have no interest in doing that in addition to what they already have to do. Python is not a company, they can’t just will such things into existence by shuffling employees around. Ironically, there is a venv implementation inside CPython (Python -m venv) and it’s slow as molasses.

Now I feel like now I'll have to match my shirts to my takes!

I don't think that's what they mean. I mean I don't know what editor Charlie is using and you still need to pick your Python interpreter in, e.g., VS Code but I suspect that's not what he understands under "activating". Putting it into a well-known place (./.venv) has led IME to most tools auto-detecting it.

You need to install your package in editable mode, if you want your local changes to reflect in the virtualenv. You'll have to separate `pip install -r requirements.txt` for JUST the requirements and `pip install -e .` to install your package.

yeah i usually search for "astral uv"

I only talk about things I actually use, so y'all have to wait until I run into a monorepo. :) There's plenty of channels on RUclips who just parrot docs & blog posts. 😬

@@The_HynekYeah, and from the docs is not really clear to me how it works (i don't have much experience too), it would be useless if people just repeat what is in the doc without really using it just for content on a channel. Hope to see a video about work-spaces with uv. There is not much content about uv yet.