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.