Skip to content

🐛 Differentiate transitive dependencies from direct third-party deps versus local deps #54

@gabe-l-hart

Description

@gabe-l-hart

Describe the bug

A clear and concise description of what the bug is.
😆

Ok, this one is gross: With the fix in #49, a direct dependency held on a parent module that was also held on a child module would be correctly placed into the common dependency set because it is needed directly by the parent. This is, unfortunately, only a first-order fix since this same situation can occur when the dependency is needed by a Third Party dependency held directly by the parent rather than a local child sub-module.

This is only a problem if the requirements list given to parse_requirements includes the transitive dependency that is only used by the Third Party dependency and is NOT used anywhere inside of the local library. This is a very unlikely circumstance, but it could conceivably arise if the Third party dependency has an open version range for the transitive dependency, but the local library needs to pin that version for some valid reason (like a security patch)..

Platform

Please provide details about the environment you are using, including the following:

  • Interpreter version:
  • Library version:

Sample Code

def test_nested_deps():
    """Make sure that direct depencencies show up in requirements
    for nested modules
    """
    requirements, extras_require = parse_requirements(
        ["sample_lib", "PyYaml", "alchemy-logging"],
        "direct_dep_nested",
        ["direct_dep_nested.nested", "direct_dep_nested.nested2"]
    )

Expected behavior

The PyYaml dependency should be in the common requirements because it's needed transitively by sample_lib which is needed directly by the top-level direct_dep_nested module.

assert requirements == sorted(["alchemy-logging", "sample_lib"])
assert extras_require == {
    "all": sorted(["sample_lib", "PyYaml", "alchemy-logging", "PyYaml"]),
    "direct_dep_nested.nested": [],
    "direct_dep_nested.nested2": [],
}

Observed behavior

The PyYaml dependency is placed into the extras for direct_dep_nested.nested because it's held as an extra set and PyYaml is not allocated as a direct dependency of the top-level direct_dep_nested module.

assert requirements == sorted(["alchemy-logging", "sample_lib"])
assert extras_require == {
    "all": sorted(["sample_lib", "PyYaml", "alchemy-logging"]),
    "direct_dep_nested.nested": ["PyYaml"],
    "direct_dep_nested.nested2": [],
}

Additional context

Discovered when trying to write a test case for #53 with @prashantgupta24

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions