`poetry check` does not take into a account path dependencies

If you have a path dependency and add a dependency to its pyproject.toml file then run poetry check --lock it will say everything is OK when it shouldn't be. It seems to me that in general the mechanism to check if the lockfile is up to date with pyproject.toml should take into account path dependencies.

I can think of two solutions:

• Include the build files for every path dependency in the content-hash metadata of poetry.lock.
• Never consider ourselves locked if there are path dependencies.

The first approach suffers from the problem that these path dependencies might not even use a pyproject.toml file / PEP 517. They could use setup.py or something super dynamic.
The second approach would be slow for the common case of path dependencies that do use PEP-517 (and likely even use poetry).

A compromise is best: if all of the path dependencies are PEP-517 dependencies then assume that the build backend is deterministic (I think this is part of the PEP / a fair assumption) and just check the content-hash (which would include a hash of all of the pyproject.toml files). If any path dependency is not PEP-517 compliant fall back to never assuming the lockfile is up to date based on the hash.

Does this seem reasonable? If so I can work on an implementation.

Start with the poetry check --lock entry point and the lockfile content-hash handling, then inspect how path dependencies read their pyproject.toml files. Compare behavior when a path dependency changes and define completion as correctly rejecting or accepting the lockfile according to the chosen deterministic-build policy; the issue names no tests or implementation files.