Jarek Potiuk

And BTW. if uv provides a build backend, you will still be able to choose it when you maintain your project - but it will also be a 3rd-party dependency...

> I think uv could provide a build backend that could be specified in pyproject.toml and used as the default when no backend is specified. It doesn't necessarily have to...

Also - again if you have proposal how to improve packaging, there are discourse threads there and PEP could be written, so I also recommend you, if you are strongly...

Yeah. I kind of agree with @mgorny that `uv` as build frontend can get by with using rust but as backend it's a bit problematic. Also another negative side of...

Yep. All that @mgorny wrote is 💯 . The difference between frontend and backend is that backend is chosen by maintainers (by settting it in build-dependencies in pyproject.toml), where frontend...

> I run Fedora and RHEL - no idea what you are talking about. I can always pull and use none-any wheels. In fact, it is way easier than pulling...

Yes. I think there are far too many things that we share that we cannot avoid `common` package. Moreover we should invest to make it in the way that it...

And I do not think we need a spike. For me it's just "common sense" (pun intended).

As an example of successufl implementation of this pattern you can look at breeze https://github.com/apache/airflow/tree/main/dev/breeze/src/airflow_breeze/utils -> this is essentially "common" - set of loose modules wirh various low-level functionalities that...

Also few opinionated answers from my side: * Should the Providers with executors be separated into providers to that they can be included on Server side? Yes * How many...