feat: use uv as a pip alternative

[MoisesGSalas]

uv is a new package installer/resolver written in rust by the same people that wrote ruff.

This is a small test to assess the viability of using uv instead of pip. It presents it self as a drop in replacement for pip, and for the most part it is, I only had to apply a single change due to limitations in editable VCS packages.

I included the change in the edx-platform requirements as a patch, but I think it makes sense to upstream it, I don't think there's any reason to use an editable VCS requirement for proctortrack (there's even the discussion about droping it from the requirements altogether).

I used a build argument to make it possible to use pip instead of uv in case people have incompatible requirements in one of their forks/patches.

Tests

Using --target=python-requirements:

command	--no-cache	time
uv	X	05:10.26
pip	X	11:15.94
uv	-	00:15.98
pip	-	01:17.16

During testing I added a RUN touch /tmp/1 instruction right before the pip install -r /openedx/edx-platform/requirements/edx/base.txt command to bust layer cache.

[regisb]

Hey Moises, these figures are getting everyone excited :) Do you think you'll be able to take this PR out of draft state? Or do you need some review?

[MoisesGSalas]

Hi @regisb, sorry for leaving this abandoned. I can work on this, but first I wanted to know people's opinion about the tool.

IMO the tool is pretty awesome and slots in almost perfectly, the same applies to the other tool developed by the same team ruff. But considering it still has not reached v1.0.0 I wonder if some people may be worried about that.

If the overall feeling is that it's worth a shot, I can clean up the PR and have it ready for review.

[regisb]

Yes, ruff is awesome, to the point that I'm considering migrating the entire code base from pylint/black to ruff. But let's talk about this another day. For now I'd be curious to see this PR brought to completion.

[DawoudSheraz]

@MoisesGSalas What are the plans for this? We can target this for nightly so that it becomes part of sumac cutoff next week.

[MoisesGSalas]

@DawoudSheraz, @regisb, sorry I couldn't find the time to retake this.

I think is ready for review. I wasn't quite sure what mechanism to use to fallback to the standard pip command if needed so I ended up using a build argument because it seemed to be the simpler one.

I rebased on top of nightly and targeted that branch. Build the image and imported a demo course just to check the platform launched correctly. I also mounted plugin using the platform-plugin-* automount and launched the dev environment and everything was working fine.

[DawoudSheraz]

why is this patch needed?

[MoisesGSalas]

edx-proctoring-proctortrack is installed as an editable VCS dependency but uv doesn't support that. I have this PR openedx/edx-platform#35654 with the same change that is used in that patch.

[regisb]

The fact that uv doesn't support editable dependencies is a blocking issue, I think. I suggest we wait until the upstream issue is resolved.

[MoisesGSalas]

I think they are not going to implement it in the near future. Note that it refers to editable remote requirements, it works fine with editable requirements in a local path.

AFAIK the only use for an editable remote requirement is that it copies all the files, but you can fix that using the MANIFEST.in.

[regisb]

I understand that. The, using uv means we will no longer be able to support adding editable dependencies to edx-platform. I'm not sure I'm ready to make that breaking change, as I expect that many people (Axim included) might add editable dependencies there.

Can we consider making an upstream PR to support that feature?

[MoisesGSalas]

This comment gave me the impression they don't want to maintain code related to this feature:

As of now we intentionally don't support this. It adds a lot of complexity and we actually don't re-clone at all upon re-running the install command (we have a cache that contains a copy of each repository, and we checkout-and-install as needed with incremental fetches).

Maybe we can keep standard pip as the default with the possibility to swap to uv if your fork of edx-platform doesn't contain any editable dependency.

[regisb]

Maybe we can keep standard pip as the default with the possibility to swap to uv if your fork of edx-platform doesn't contain any editable dependency.

That's already the case. People can install uv in their own Docker image and alias pip='uv pip', all with a Tutor plugin.

[MoisesGSalas]

But that wouldn't work for the RUN commands in the Dockerfile, right? The main appeal would be to use it in the python-requirements layer.