Fix hardcoded reliance on pip

[vpetrigo]

This is an attempt to fix the issue described here juftin/hatch-pip-compile#85.

As it was discussed there, since hatch already depends on uv there is no need to rely on pip install during environment requirements resolution, because it may be not available.

[juftin]

uv makes a singular Python import available, find_uv_bin - that may be more reliable than python -m uv ... 🤔
https://github.com/astral-sh/uv/blob/54b3a438d03483c6e76f05168bd417657b693e4b/python/uv/_find_uv.py#L8C5-L8C16

from uv import find_uv_bin ... uv_bin = find_uv_bin() pip_command = [uv_bin, '-u', '-m', 'pip']

This likely works the same though

[vpetrigo]

Updated!

[juftin]

This is great, I was imagining the fix for this would be some complicated piece of work - but this is a really nice, targeted swap of pip for uv pip only in ensure_plugin_dependencies

[juftin]

EDIT: This test is passing confirming this works, it will fail if you swap git+https://github.com/vpetrigo/hatch.git@fix/hardcoded-reliance-on-pip with hatch

FROM fedora:latest RUN dnf install -y git COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ RUN uv python install 3.12 RUN uv tool install git+https://github.com/vpetrigo/hatch.git@fix/hardcoded-reliance-on-pip ENV PATH="/root/.local/bin:${PATH}" WORKDIR /work RUN touch /work/pyproject.toml RUN cat <<EOF > /work/pyproject.toml [build-system] requires = ["hatchling"] build-backend = "hatchling.build" [project] name = "foo" version = "0.0.1" dependencies = ["requests"] [tool.hatch.env] requires = [ "hatch-pip-compile" ] [tool.hatch.envs.default] installer = "uv" type = "pip-compile" pip-compile-resolver = "uv" pip-compile-installer = "uv" EOF RUN mkdir /work/foo RUN touch /work/foo/__init__.py CMD ["hatch", "run", "head", "requirements.txt"]

docker build . --tag hatch-pip-compile-test docker run --rm -it hatch-pip-compile-test

# # This file is autogenerated by hatch-pip-compile with Python 3.12 # # - requests # certifi==2024.12.14  # via requests charset-normalizer==3.4.1  # via requests

[juftin]

This actually fails now since we've replaced sys.executable -m pip with find_uv_bin 😢

Looks like uv doesn't know what environment to install into

error: No virtual environment found; run `uv venv` to create an environment, or pass `--system` to install into a non-virtual environment 

[vpetrigo]

Rolled back for now to [sys.executable, '-u', '-m', 'uv', 'pip'].

[vpetrigo]

What may work is the following command:

uv_bin = find_uv_bin() pip_command = [uv_bin, 'pip'] pip_command.extend(['install', '--directory', str(pathlib.Path(sys.executable).parent.parent)])

Not sure if it is more reliable than calling a uv module with venv Python.

[vpetrigo]

Pushed those changes for review just in the case that approach with find_uv_bin is preferable. 😅

[juftin]

I was thinking about two options that would work here:

The first option essentially calls python -m uv pip which when invoked as a module discovers the Python environment it belongs to

pip_command = [sys.executable, "-m", "uv", "pip"] pip_command.extend(["install"])

The second option is to call the find_uv_bin method, but also passes the current Python interpreter using the --python argument

uv_binary = find_uv_bin() pip_command = [uv_binary, "pip"] pip_command.extend(["install", "--python", sys.executable])

Honestly, I think both of these options do the same thing 🤷 - I'm fine with whatever you and Ofek like

[vpetrigo]

I updated the implementation for the last option with passing --python switch as it is more readable and less confusing than passing venv Python directory with --directory switch. Run through the tests in hatch and with the container you prepared - all passed on my end.

[vpetrigo]

@ofek would you please re-approve workflows once again, I fixed formatting errors reported. I am really sorry to bother you. 😔

[vpetrigo]

Not sure why 3.12 on Linux failed. Re-run that in my repo and it passed. 🤷