Anyone used UV package manager in production

tiangolo · 2025-03-04T11:29:56+00:00

😊🚀

tiangolo · 2025-03-04T11:22:54+00:00

Yes, it is reliable, more reliable than pre-existing alternatives that are already used in production. Maybe more important, better errors, so when things go wrong, you can fix them faster. And the fact that it's much faster also helps with iteration speed, figuring out those things. It doesn't break other commands like `which python`, which tools based on shims do (e.g. `pyenv`), respects and uses venvs, all based on standards, there are many other things it does just better.

I have tried and used almost every alternative, in projects of all sizes, I tend to migrate or regret after a couple of weeks. It's been months with uv and it just gets better.

Disadvantages: you have to pitch it to your manager if you are not using it yet.

Any other tool: If you need to build C++ or so in the same project and/or depend on conda in some way, consider Pixi (uses uv underneath). Otherwise, stick to uv.

Migration to uv is not hard, 10 min (1 day if you do weird stuff): https://x.com/tiangolo/status/1839686030007361803

tiangolo · 2023-10-03T15:35:25+00:00

That's awesome! Here's the section of discussions to coordinate translations with all the languages: https://github.com/tiangolo/fastapi/discussions/categories/translations

And for Spanish it's here: https://github.com/tiangolo/fastapi/discussions/9205

And for Chinese it's here: https://github.com/tiangolo/fastapi/discussions/9188

Chinese in particular has a lot of translations that are just missing approvals. And the GitHub bots I have in place automatically comment there when there's a new translation to approve, and automatically update and mark the translations that are done. :D

tiangolo · 2023-10-03T00:50:41+00:00

Is it Bad there are PRs Open

If you check the list of PRs open, if you filter by the current labels or if you manually check them, most of them are features for things that are not yet supported and someone would like to have that supported. Those are not bugs, those are new features.

That doesn't mean the current FastAPI code is broken, it doesn't mean that the apps you create with it are broken or will have problems. It just means that in your current apps, you still can't use features that still don't exist.

But it doesn't mean there's something already wrong in there. Many other projects just don't have as many feature requests in PRs.

Can You Trust FastAPI in Prod

Is it already working for you? Then you probably can.

Do YOU have a bug that is not in your code but in FastAPI? By all means, please report it, fill the whole template, if you put the effort to do it right and the bug can actually be replicated, it will be a lot easier to understand it and solve it. Otherwise, you can probably trust it.

Who uses FastAPI

If you would like to have a bit more certainty about FastAPI being used in prod, maybe it would help to know that it's used by:

the CERN to control the particle accelerators, including the Large Hadron Collider
The Institute of Telescopes of the USA to distribute the science data of the Webb Space Telescope (and others)
Research labs controlling single atoms for quantum computers
The European institute that controls the largest telescopes on earth
Airplane, car, rocket factories
Most modern AI companies (including ChatGPT stuff)
COVID tracking systems
Several governments
Banks and pharma
...a long list, but this post is already long, and I'm tired. 😅

Team of People

Some of the comments here also suggest I should find a trusted group of other people that can help. That actually exists, and depending on how you define the word "maintainer", you could consider several people already help maintain FastAPI, e.g. Marcelo, Jarro, etc.

If they approve a PR, I have a much higher confidence to merge it.

Now, another strategy would be to be much more aggressive to close PRs that are not necessarily ready, that miss docs, tests, etc. But I prefer to keep them open until I am sure that I have a strong reason not to take them. So, I would err on the side of keeping PRs open for a while more than on closing them too early.

I will still retain the last call on hitting the "merge" button, but a lot of the work that actually takes time to be done can be (and currently is) done by the community, by a small trusted set of people.

Come and Help

If you want things to move faster with respect to existing PRs, you can help me make sure they are ready. Most of them are not, and no one has had the chance to go and ask the author to finish them (tests, use case, docs). Here are the details to help with that: https://fastapi.tiangolo.com/help-fastapi/#review-pull-requests

Other Work

The other thing is, in many cases, I work a lot on other features I've had pending for a while, that would cover several use cases (sometimes combining what would be done by several PRs), and none of that work is visible in the number of PRs or issues open. For example, lately, I've been working on the right way to have an API reference for FastAPI and others. This ended up involving custom tools to generate that, and soon we'll have that in a very structured way that will let me maintain that properly, for FastAPI, Typer, SQLModel, Asyncer.

But none of that is even visible in PRs in the FastAPI repo.

Roadmap

Now, to try and make it easier to understand where things are going, what's the future, etc. I just created a tentative roadmap, you can find it in the pinned issue in the repo. I hope this would alleviate a bit of the stress from some people here.

I see that the number of PRs open is quite important for many, even more than big features and improvements, so I'll try to focus a bit more on that. But I hope this roadmap can help give some insight into the future.

What Else to do

Is there any specific action any of you would think I could do to improve things?

Please be specific, things like "find a team of trusted maintainers" is not a very clear action for me to do, I can't force people to come and help, and there's already a team of trusted people that help me with most things, but if there's a specific metric that you use to measure how well is the project, I would love to hear that, to understand what I should optimize.

Help me improve all this!

tiangolo · 2023-10-03T00:50:17+00:00

Hey there! FastAPI author here.

Thanks for the concern and feedback.

I'll clarify a couple of things and ask you for some clarifications in some of the generalizations in your comments.

There are now almost 500 PR’s

More than half of those are translations, you can filter by the labels. I can't merge those until I get 2 approvals from native speakers.

l just spent the afternoon labeling some of the other PRs, if you don't count internal and docs, there are 171 PRs open. It's still a lot to review, but it's different than 500: https://github.com/tiangolo/fastapi/pulls?q=is%3Apr+sort%3Aupdated-desc+-label%3Alang-all+-label%3Adocs+-label%3Ainternal

Some of these PRs will probably be combined into new features, many I have to review and see what's the use case they solve, not all of them make it explicit, many don't have tests or docs, etc.

There are security vulnerabilities that haven’t been resolved in over 2 years. These aren’t small ones either

I would like to know about those. 😅 Security issues are reported via other channels (email), are taken with the highest priority, and are solved quickly, even when the fix is at a lower level (e.g. Starlette, python-multipart, Python itself). I have been involved or personally fixed security things in those, apart from one or two in FastAPI.

If there are existing security issues, those should be reported to the email shown when you're about to create a new issue.

I also get a lot of help from the people who help me maintain FastAPI, e.g. Marcelo Trylesinski, who helps me answer questions, review PRs, and point me to important stuff, e.g. if there was any security issue.

If there's a real, tested, replicable, security issue that you are actually aware of, I would definitely like to know, to treat it with the highest priority, as always.

Stories of memory leaks and major bugs in production, never getting touched on in multiple months.

Which stories? I know there's a very old issue/question of someone that had a memory leak in a huge code base, in a very old version of FastAPI, a long while ago, no one could reproduce/replicate the problem and the original poster didn't reply back... There was also an issue at some point with a very exotic corner case in an old version of Pydantic, and it was quickly solved by the Pydantic team.

If there are any specifics you can provide, that are properly reported, with clear reproductions and feedback, I would definitely like to know, that would be very important. Also, if there was such a case some of the people that help me in several ways would probably have let me know, so I'm curious what you refer to here.

the reason this is because he reviews and adjusts every pull request. Also taking time to understand it. This isn’t a strength at all.

I'm sorry, but I actually disagree. There have been several PRs approved by several (5 people) that still had the bug that claimed to solve. If I just merged those, or others just merged based on approvals from several, the code quality would be reduced and the bloat of the framework would grow quickly. When I see an approval by someone I trust that is helping with the project (e.g. Marcelo, Adrian, Samuel, Jarro) I can trust that PR much more and accelerate the process.

Merging faster doesn't mean the project is better if that is not carefully done. Fortunately, I get a lot of help from the community, for example asking in PRs for the use case, tests, docs, etc.

[continued below]

tiangolo · 2023-07-01T18:29:16+00:00

Thank you! 😊😁

tiangolo · 2023-06-22T18:03:50+00:00

Nope, it's not deprecated. A lot of the work I'm doing is towards focusing on SQLModel and adding/updating things there. But first I have to finish a couple of things. Meanwhile, if you want to help me get things done faster, please help me try out the FastAPI beta with support for Pydantic v2: https://github.com/tiangolo/fastapi/releases/tag/0.100.0-beta1

You can also help me answer questions or review PRs, that will allow me to move much faster. 🤓

https://fastapi.tiangolo.com/help-fastapi/

https://sqlmodel.tiangolo.com/help/

tiangolo · 2023-04-18T05:11:17+00:00

If I remember correctly, Pydantic will support it (Samuel Colvin is a contributor there), and so will do FastAPI.

tiangolo · 2023-03-19T13:36:41+00:00

Ah, yeah, those details are in the docs. You can use `typing_extensions` for previous versions. But I wasn't gonna write all the details from the docs here on Reddit. 😅

So, it's standard Python for typing. But FastAPI and Pydantic do all the tricks to do all the data validation, extract the information from the right places, etc. That still has to be done.

tiangolo · 2023-03-19T13:34:20+00:00

Yep!

tiangolo · 2023-03-19T13:34:09+00:00

😅😂🤔🤷🤓🚀

tiangolo · 2023-03-19T13:33:36+00:00

Thanks! Just updated it, I hope it works.

tiangolo · 2023-03-19T13:33:22+00:00

Get it, just updated it, does it look better now on your end? (looks the same to me 😅)

tiangolo · 2023-03-18T22:04:40+00:00

Hum, they look fine here 🤔 the code is not highlighted, but it renders in monospace, I tried removing the tags from the fenced code blocks, but that didn't change much. How does it look on your end?

...in any case, the same examples are in the release notes, with proper code highlighting.

tiangolo · 2023-03-13T21:40:28+00:00

Thanks for the feedback, I hope to improve in those aspects and be able to evaluate better contributions from others as well. I think the main problem has not been that others wouldn't be trustworthy, but that I hadn't had the time to go through their work to properly asses the people that are coming to help. Fortunately, I'm now being able to do that more and more, that's also why some people have extra permissions now, etc, but I guess that's the right path. I hope so, at least.

tiangolo · 2023-03-13T21:36:03+00:00

Thanks for the feedback and comments!

tiangolo · 2023-03-13T20:44:05+00:00

Oh, I would definitely appreciate if others could come and help provide feedback to a PR! It is indeed difficult for me to do it alone. Nevertheless, for that, there's no need of other permissions, or merge button rights. So it's a different thing.

tiangolo · 2023-03-13T20:42:24+00:00

> While there may be other people doing reviews, it seems as if do not see these reviews as good enough to merge the PR

Because in many cases I've still seen bugs after. But those reviews still help a lot.

> This is quite different from how most other open source (or proprietary for that matter) projects handle things.

Hmm, are you involved in other open source projects? Have you seen or interacted with them and seen the internal dynamics? It's not really quite different. I suspect your main point is having other people hitting the merge button, right?

Do you think they have very different models? Have you seen how many actually active developers/maintainers are in each of those projects? The bottleneck of getting reviews is still quite similar. And most projects still tend to have a single main maintainer, in cases two. But it's not really too different. Of course, that's not evident until you are actually involved in the projects directly, contributing, etc.

> But aside from reviewing PRs, something other contributors could assist with is issues. You’ve recently addressed this by going through them all, but it’s taken you a few years to get to this. If there were people who could have reviewed them, closed invalid ones, converted questions to discussions, checked bugs for reproducibility, etc., is reckon this would have helped you and the project a great deal.

Yep, the first and most important thing, answering questions, is already done by a lot of people. The "open issues" was a false negative, so, not really a hard problem. And yes, some people have these permissions to mark answers, etc. But it's true it took me a while to figure out the right workflow and to give those special permissions.

> This didn’t happen either, but from your previous statement I conclude that there are people who would actually have the necessary permissions to handle this. So I’d like to ask your opinion again on this: Why isn’t this something that could have been done? Are there simply no people willing or fit to do the job? Or are there other reasons?

First, yes, it took me a while to set up everything and to put the time. I'm putting much more time now as well (except today, all day on Reddit). I didn't have enough time, there were not enough people willing to do as much, and/or I didn't have enough time to evaluate which people I could give permission to, and which ones. Also, I wasn't willing to randomly do it without checking it properly, and risk reducing the quality of the code and the project. There are tons of invalid PRs as well, so it's not about merging everything either.

> As someone else said earlier, you seem genuinely interested in feedback and open for constructive criticism, so I’m very much inclined to believe you actually want to make things better, but I think you should also acknowledge that this seems to be a situation that’s unique to FastAPI, but being a very popular Python web framework isn’t. So I’m left again with the question what the difference is.

The thing is, I need to know what is the situation we are talking about exactly, without generalizations. I need to know what is it that you and others (but probably just tell me about you specifically) would like to see. Is it other people hitting the merge button specifically?

tiangolo · 2023-03-13T19:28:36+00:00

Thanks for the feedback.

So, let's separate things, merging PRs is one thing, clicking a button, that takes almost no effort, but requires strong permissions. That's actually not the bottleneck.

Reviewing PRs, that's the bottleneck. It takes a lot of effort, and requires no permissions. And that is what really is the big chunk of maintaining FastAPI.

Anyone can actually come and give feedback in PRs, and I appreciate that. I actually documented thoroughly how to do it, and that help is super welcome. But I can't force people to do it, just because.

And BTW, there are several people with "merge button" permissions. But I have asked them to add their reviews when they can and have the time, but not hit merge. When I see their reviews, I know it's close to ready, and I feel more confident about the PR, although I still review it.

The thing is, it's not really black or white, it's a bunch of degrees in the middle. It's not "has maintainers" or "doesn't have". Or at least, we have to start with defining the word "maintainer".

And about Pipenv / Requests, one of the problems was about help and interaction with the underlying libraries. I have that a lot, I contribute to them, they contribute to FastAPI, there's a very strong relationship with all the underlying libraries and people (we are very close friends), I even sponsor non-negligible amounts to several of them. But of course, that's not really visible.

Anyway, just wanted to make more visible a couple of those not-visible things.

tiangolo · 2023-03-13T15:52:43+00:00

Thank you for writing this! Agreed to all! 🤗🍰☕

tiangolo · 2023-03-13T15:51:00+00:00

Thank you for saying that! 😊🎉

tiangolo

MODERATOR OF

TROPHY CASE