✨ exhaustive dependencies_in_sync

[juftin]

resolves #50

Changes

Instead of only checking packages specified on the pyproject.toml when running self.dependencies_in_sync() this PR uses all packages from the lockfile instead.

This is done by reading an exhaustive list of dependencies from the lockfile and passing them to hatchling.dep.core.dependencies_in_sync.

This PR uses piptools._compat.pip_compat to interface with the lockfile.

[juftin]

I'm super happy with this one. It goes along perfectly with #48. I tested by changing a minor version of a package on the lockfile and it picked it up automatically and installed the new version.

[juftin]

I found our usage of pip-tools API to be compatible with 6.x and 7.x. 8.x isn't released so I pinned it on >=6,<8. This doesn't affect which version of pip-tools gets installed into the virtualenvs and invoked via the API though.

[oprypin]

Please don't add upper version constraints.
https://iscinumpy.dev/post/bound-version-constraints/

[juftin]

Yeah, that was my initial inclination as well - thanks for the gut check. I'll remove the upper bound and keep an eye out for any breaking API changes

[oprypin]

I see that a private import is used.. that's definitely more scary then 😕
Is there any way to instead copy their code or something

[juftin]

The private import is the reason I was so strict on the version pinning. Unfortunately it's private imports all the way down as pip-tools uses a bunch of private methods from pip https://github.com/jazzband/pip-tools/blob/main/piptools/_compat/pip_compat.py

Ultimately it's pip._internal.req.parse_requirements that this PR is leveraging.

[juftin]

I could trade pip-tools private imports for pip private imports. Not sure if this makes anything better though.

from packaging.requirements import Requirement
from pip._internal.network.session import PipSession
from pip._internal.req import parse_requirements
from pip._internal.req.constructors import install_req_from_parsed_requirement


def lockfile_to_requirements(lockfile: str) -> list[Requirement]:
    requirements = []
    session = PipSession()
    for parsed_req in parse_requirements(
        lockfile, session, finder=None, options=None, constraint=False
    ):
        install_req = install_req_from_parsed_requirement(parsed_req, isolated=False)
        requirements.append(install_req.req)
    return requirements

[oprypin]

Yeah nothing to do about imports then.

I was just checking that pip-tools doesn't pin pip's version. But of course that makes sense, pinning it could cause unimaginable issues

[juftin]

They enforce >= 22.2 https://github.com/jazzband/pip-tools/blob/e02d186efc74bd2509b4a0f038b0184bdc106e42/pyproject.toml#L41

So just to confirm here, you're recommending to go forward with the private piptools import and to remove the upper bound dependency?

[oprypin]

I think so..

[juftin]

🎉 This PR is included in version 1.9.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀