[ANE-610] Adds PDM Support

[meghfossa]

Overview

This PR, adds initial PDM support.

It does not support,

• local dependency (these are path dependencies)
• non-git version control sources

Acceptance criteria

• As a user, I can analyze PDM project when I have pyproject.toml and pdm.lock
• As a user, I can analyze PDM project when I only have pyproject.toml

Testing plan

Prereq

git checkout master && git pull origin && git checkout feat/adds-pdm && make install-dev

PDM (with lockfile)

1. Create pdm project
2. Perform pdm lock (to create lockfile)
3. Perform fossa-dev analyze

Or clone example pdm project: https://github.com/pdm-project/pdm

# .fossa.yml
version: 3
paths:
  exclude:
    - ./tests/

PDM (without lockfile)

1. Create pdm project (ensure there is no lockfile)
2. Perform fossa-dev analyze

Or clone example pdm project: https://github.com/pdm-project/pdm, and rm pdm.lock.

# .fossa.yml
version: 3
paths:
  exclude:
    - ./tests/

Risks

N/A

Metrics

N/A

References

https://fossa.atlassian.net/browse/ANE-610

Checklist

• 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 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. 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).

[csasarak]

I'm only requesting changes to get a bit more clarity on how the strategies are organized here. Otherwise, this looks good to me.

[csasarak]

What is the distinction here between URLType and PathType? I ask mainly because we'll do some work with path deps in the near-ish future and some of them probably won't map to a URL fetcher. I don't think this would be a problem because it's easy to add new types but I thought I'd ask.

[meghfossa]

good catch - I changed to path now. These should be filtered out regardless.

I'm adding something like enrich :: (...) => Graphing Dependency -> m (Graphing Dependency) in upcoming conan pr, which would handle path dependencies. So I left it here for now.

[csasarak]

I'm interested in hearing your thoughts about this as we have upcoming tickets (ANE-383/ANE-893) which are both focused on Go path deps. We were hoping to use them as a model for how to do it for other path deps. In particular a challenge we have to solve is how to present path deps in the UI in a way that isn't confusing or misleading.

[meghfossa]

I wasn't aware re ANE-383/ANE-893. I will bring this up in our slack channel. If ANE-383 is already slotted, I will defer some of the conan work for later, so we can have consistent model.

[csasarak]

I'm interested in hearing your thoughts about this as we have upcoming tickets (ANE-383/ANE-893) which are both focused on Go path deps. We were hoping to use them as a model for how to do it for other path deps. In particular a challenge we have to solve is how to present path deps in the UI in a way that isn't confusing or misleading.