Are there any drawbacks/tradeoff for using a lockfile? We are trying to use one in a monorepo for python packages but have some concerns about how it could silence some errors when package dependencies change. For example, if a dependent package releases a new version, a developer might pull this update locally, but the CI/CD pipeline using the lockfile would not, potentially leading to discrepancies.

Well, typically developers would use the same lockfile locally as well.

oh I'm more so talking about when a developer installs a package by running

pip install

for example. Since no lockfile is involved, there's no way to ensure the dependencies it installs are consistent with what's in the lockfile if that makes sense

That isn’t a recommended workflow - you typically want local developers and your CI processes to use the same commands and lockfiles and stuff

I think I need to make my situation a bit more clear. Basically, We have a monorepo that builds/tests packages and upload them to PyPI with Pants. When a user try to install those packages in their own repos, they might end up installing a different version of a transitive dependency since there are no Pants or lockfiles in the repo. I'm not talking about running

pip install

in the monorepo if that makes sense.

Ah yes, that makes sense. So you’re talking about the requirements of your own wheels. That is indeed a different situation.

I believe Pants is generating the metadata. We have a pyproject.toml in each package directory but it's only used for specifying package-specific requirements.

python_requirements(
        name="reqs",
        source="pyproject.toml",
    )

Yeah, so Pants will generate relatively tight requirements for the wheels, but certainly not locked down like they are with the lockfile.

I see. That makes sense. Thanks!

If they conform to the requirement constraints, yes