My opinion: I think there is a place for a number of such tools. For a long time the packaging team and `pip` team have been working not only on `pip` implementation but also (and most importantly) to make sure that what `pip` does is to be the beacon of standardisation of packaging APIs and PEPs. It will never IMHO have a lot of the fancy features that other tools might provide (like the ones I mentioned). It will always be there to provide the robust and solid CLI to run all packaging things, but there are plenty of opportunities to provide improved or modified, or more (or less) opinionated ways of doing things that are addressing some cases that `pip` team simply will not be able or willing to handle, preferring "pure" standard approach vs. implement all the optional things. For example the way how pre-releases are handled can be improved to be more selective. The PEP describing it gives the tools an option to add more fancy behaviours (some of which we could find useful in our CI tooling). Should `pip` implement those - I don't think so. It would distract maintainers from other more important things. It is quite ok to use other tooling in places like our CI, where they do some parts of the installation better.
For me `pip` is going more into the direction of `usable reference implementation of package installed` - any standard/ PEP will not matter if `pip` does not implement it. But others might go in different directions and implement some less popular features and do it better, faster, with greater flexibility. IMHO it's a win-win. J. On Mon, Feb 19, 2024 at 11:40 PM Andrey Anshin <[email protected]> wrote: > Yesterday my friend shared with me that tool and I've been told that more > presumably it would be a niche tool. I've been told "who needs yet another > installer which stands to resolve all your problems' '. > I guess I was wrong? > > On Tue, 20 Feb 2024 at 00:53, Jarek Potiuk <[email protected]> wrote: > > > Hey everyone, > > > > Few days ago the ruff creators have released a new tool uv - which is an > > extremely fast (written in rust) and fully featured tool generally fully > > compatible with `pip`. > > > > Blog post here: https://astral.sh/blog/uv > > > > It looks like It has a number of things that would make our CI cases and > > tooling quite a bit faster and better including a few things that I have > > implemented some workarounds for and some that I have not > > implemented because `pip` had no good solution. > > > > I looked at the docs and it solves some problems that are currently > > difficult or impossible to handle with `pip`: > > > > * ability to use overrides (which are constraints on steroids - allowing > to > > override limits specified by the packages - this will be very useful to > > better handle our cases with "chicken-egg" providers (for example like we > > had in FAB) where we have pre-release packages depending on each other > > > > * different resolution strategies including --resolution=lowest which > will > > finally allow us to see whether airflow's lower bounds are still holding > > (i.e. - will our test still pass if we use the lowest supported version > of > > our dependencies? this is something i wanted to do for quite some time > and > > recorded an issue for that - > > https://github.com/apache/airflow/issues/35549 > > but lack of tooling support made it a wish, with `--resolution=lowest` it > > seems like super-easy thing to do. > > > > * It is said to be many, many times faster - with better caching and > > resolution speeds (similarly like with ruff they claim orders of > magnitude > > speedups in a number of cases). We can likely make very good use of it > and > > speed up some parts of our CI workflow significantly. > > > > I might likely do some experimenting with uv in our toolchain, but wanted > > to make sure we are all aware of it - and ask if someone has something > > against it (and maybe someone would like to do some work there trying it > > out - I will be happy to guide others with the dev/tooling mindset and > > incline to do some changes there/review PRs and cooperate on testing > those > > things. > > > > It's not a user-facing change, and I do not think we want to get rid of > > `pip` as an installation tool in general (in our images and user facing > > side) - it's mostly an internal CI tooling improvement I am thinking of. > > Maybe at some point in time we can recommend it also for development > > workflows, and maybe someday it will gain enough popularity to think > about > > recommending it to our users, but definitely not now nor in even mid-term > > future. > > > > Let me know what you think. > > > > Repo here: https://github.com/astral-sh/uv > > > > J. > > >
