It's hard to detect if a setup.py-based-project has been updated, especially if its properties (such as version or install_requires) are defined in a different file (from <package> import version, setuptools.setup(version=version, ...)).

There's several solutions for handling setup.py, each with their own tradeoff:

• The current solution: just check for changes in setup.py. Downside: packages that have properties defined in other files aren't recognized as modified properly
  • The workaround here is to manually cut the package out of the lockfile, then regenerate the lockfile afterwards. This isn't great usability, but fortunately no packages (at the time of writing) hit this edge case
• Alternatively, include all files in a package when determining if it's been changed. Downside: performance cost in hashing that many files
• Another option: parse setup.py AST, look for imported files, include them in the hash. Downside: pretty complex

My favourite solution here is to no longer allow referring to vendored packages with just setup.py: either vendor the distribution information (SDist), or only vendor packages which use pyproject.toml instead of setup.py in their "source" form.

Unfortunately, the blockers here are:

• dlmanager (dist on PyPI is invalid, project uses setup.py)
• gyp (dist on PyPI is really old, project uses setup.py)