fossa-cli icon indicating copy to clipboard operation
fossa-cli copied to clipboard

[ANE-1400] Fix pipenv transitive dependencies being reported as direct

Open ryanlink opened this issue 1 year ago • 0 comments

Overview

The pipenv strategy in fossa-cli is currently reporting all dependencies from pipenv graph as direct dependencies, even when they are actually transitive dependencies. This causes incorrect dependency trees in FOSSA, where transitive dependencies appear at the top level.

For example, if a project has:

  • Direct dependency: requests
  • Transitive dependency: urllib3 (required by requests)

The current implementation shows both requests and urllib3 as direct dependencies, which is incorrect.

Changes

  1. Modified buildEdges in Pipenv.hs to only mark top-level dependencies from pipenv graph as direct dependencies
  2. Added a helper function mkEdgesRec that properly handles the dependency tree structure
  3. Added a test case in PipenvSpec.hs to verify correct handling of transitive dependencies
  4. Updated changelog with the fix

Testing

Acceptance criteria

pipenv transitive dependencies should no longer be reported as direct dependencies.

Testing plan

  • Added unit test verifying that:
    • Direct dependencies are correctly marked as direct
    • Transitive dependencies are not marked as direct
    • Dependency relationships are preserved
  • Manually tested with the example project from the GoodData support ticket:

git clone https://github.com/gooddata/gooddata-python-sdk.git cd gooddata-python-sdk/gooddata-pandas pipenv install -r requirements.txt fossa analyze

Risks

Highlight any areas that you're unsure of, want feedback on, or want reviewers to pay particular attention to.

Example: I'm not sure I did X correctly, can reviewers please double-check that for me?

Metrics

Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it

References

ANE-1400 Support tickets: TKT-9347 TKT-9567 TKT-10407

Checklist

  • [x] I added tests for this PR's change (or explained in the PR description why tests don't make sense).
  • [ ] If this PR introduced a user-visible change, I added documentation into docs/.
  • [ ] If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
  • [x] If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
  • [ ] If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
  • [ ] If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

ryanlink avatar Feb 06 '25 22:02 ryanlink