Feedback: "Managing Application Dependencies" and "Packaging Python Projects" Tutorials Are Incompatible

Hi! Thank you for writing all of this documentation so clearly, it has been extremely helpful.

"Managing Application Dependencies" suggests Pipenv. "Packaging Python Projects" defaults to hatchling. I assumed that you could follow the two tutorials, in-order, and end up with a working python project, but I had to write a shim to teach hatchling to read a Pipfile.lock. Pipenv doesn't seem to interact with pyproject.toml, and Hatch seems to only read dependencies from there.

I don't know enough about python packaging to suggest a solution. I think you should be able to follow the tutorials as-written and have them be compatible.

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.hatch.metadata.hooks.custom]
path = ".ci/dependencies.py"

"""Dynamically update the dependencies metadata based on the Pipfile.lock file."""  # noqa: INP001

import json
from typing import Any

from hatchling.metadata.plugin.interface import MetadataHookInterface


class PipfileLockedDependencies(MetadataHookInterface):
    def update(self, metadata: dict[Any, Any]) -> None:
        with open("Pipfile.lock") as f:
            pipfile_lock_data = json.load(f)

        metadata["dependencies"] = [
            f"{pkg}{data['version']}"
            for pkg, data in pipfile_lock_data["default"].items()
        ]

I feel somewhat bad about suggesting new projects all include this, but at my organization we really want to make locking dependencies the norm. I hope I am missing something obvious.

Read the Managing Application Dependencies and Packaging Python Projects tutorials, then compare their Pipenv/Pipfile.lock and hatchling/pyproject.toml workflows. Use the reported pyproject.toml and .ci/dependencies.py example to reproduce the incompatibility. Done means the tutorials work together as written, or clearly explain the supported dependency-locking workflow and any incompatibility.