Project: FOSSA (Provisioning / Security & Compliance)
File: pdm.md

is a tool for dependency management and packaging in Python. Find files named `pyproject.toml` and `pdm.lock`. | Strategy | Direct Deps | Transitive Deps | Edges | | - | | | | | `pyproject.toml` and `pdm.lock` are discovered | :heavycheckmark: | :heavycheckmark: | :heavycheckmark: | | Only `pyproject.toml` is discovered | :heavycheckmark: | :x: | :x: | | Only `pdm.lock` is discovered | :x: | :x: | :x: | :heavycheckmark: - Supported in all projects :x: - Not Supported We parse `pyproject.toml` to find, direct dependencies, from `[project]'s dependencies`, direct optional dependencies, from `[project.optional-dependencies]`, direct development dependencies, from `[tool.pdm.dev-dependencies]` FOSSA does not consider optional dependencies, as production dependencies for PDM, and as such they will be discarded from final analysis findings. If `pdm.lock` file is discovered, following will be analyzed from lockfile to supplement the analyses: `[[package]]` - package's dependencies `[[package]].name` - name of the package `[[package]].version` - resolved version of the package `[[package]].dependencies` - list of dependencies `[[package]].git` - git url, if the dependency's source is git vcs `[[package]].revision` - revision associated with the git vcs `[[package]].path` - local path, if the dependency's source is filesystem To identify, if the package is `production` dependency, or `development` dependency, `fossa-cli` hydrates the dependency graph from lockfile with `pyrpoject.toml`. `fossa-cli` marks any dependency in `pyproject.toml`'s `[]` as production dependencies, and rest as development dependencies. `fossa-cli` propogates this dependency environment marking to all transitive dependencies, marking all reachable nodes. For example, ```mermaid flowchart TD A("requests@2.25.1") --> B("certifi@2023.5.7"):::unknown A:::prod --> C("chardet@4.0.0"):::unknown A --> D("idna@2.10"):::unknown A --> E("urllib3@1.26.16"):::unknown J("pytest@7.3.1"):::dev --> K("iniconfig@2.0.0"):::unknown J --> L("packaging@23.1"):::unknown J --> M("pluggy@1.0.0"):::unknown classDef prod fill:#f96 classDef dev fill:#ccc classDef unknown fill:#fff ``` would be hydrated to following graph: ```mermaid flowchart TD A("requests@2.25.1") --> B("certifi@2023.5.7"):::prod A:::prod --> C("chardet@4.0.0"):::prod A --> D("idna@2.10"):::prod A --> E("urllib3@1.26.16"):::prod J("pytest@7.3.1"):::dev --> K("iniconfig@2.0.0"):::dev J --> L("packaging@23.1"):::dev J --> M("pluggy@1.0.0"):::dev classDef prod fill:#f96 classDef dev fill:#ccc classDef unknown fill:#fff ``` In this graphs, orange signifies production dependency, and gray signifies development dependency, whereas white signifies unknown environment. If a dependency shared parent who had `development` marking, as well as `production` marking, `fossa-cli` marks this dependency as production dependency. Any will not be reported, by default. To enable, local dependencies in analysis, enable experimental path dependencies. Learn more about . Any dependency using: `hg` (mercurial), `svn` (subversion), `bzr` (bazaar) source, will not be reported. Create `pyproject.toml` file ```toml [project] name = "myexample" version = "1.0.0" description = "example pyproject toml file" authors = [ {name = "fossa", email = "support@fossa.com"}, ] dependencies = [ "requests==2.25.1", ] requires-python = ">=3.11" license = {text = "MIT"}

extra = ["black"] [tool.pdm.dev-dependencies] test = [ "pytest>=7.3.1", ] ``` Perform `pdm lock` to create `pdm.lock` file. ```toml [[package]] name = "certifi" version = "2023.5.7" requires_python = ">=3.6" summary = "Python package for providing Mozilla's CA Bundle." [[package]] name = "chardet" version = "4.0.0" requires_python = ">=2.7, !=3.0., !=3.1., !=3.2., !=3.3., !=3.4.*" summary = "Universal encoding detector for Python 2 and 3" [[package]] name = "colorama" version = "0.4.6" requires_python = "!=3.0.,!=3.1.,!=3.2.,!=3.3.,!=3.4.,!=3.5.,!=3.6.*,>=2.7" summary = "Cross-platform colored terminal text." [[package]] name = "idna" version = "2.10" requires_python = ">=2.7, !=3.0., !=3.1., !=3.2., !=3.3." summary = "Internationalized Domain Names in Applications (IDNA)" [[package]] name = "iniconfig" version = "2.0.0" requires_python = ">=3.7" summary = "brain-dead simple config-ini parsing" [[package]] name = "packaging" version = "23.1" requires_python = ">=3.7" summary = "Core utilities for Python packages" [[package]] name = "pluggy" version = "1.0.0" requires_python = ">=3.6" summary = "plugin and hook calling mechanisms for python" [[package]] name = "pytest" version = "7.3.1" requires_python = ">=3.7" summary = "pytest: simple powerful testing with Python" dependencies = [ "colorama; sys_platform == \"win32\"", "iniconfig", "packaging", "pluggy<2.0,>=0.12", ] [[package]] name = "requests" version = "2.25.1" requires_python = ">=2.7, !=3.0., !=3.1., !=3.2., !=3.3., !=3.4.*" summary = "Python HTTP for Humans." dependencies = [ "certifi>=2017.4.17", "chardet<5,>=3.0.2", "idna<3,>=2.5", "urllib3<1.27,>=1.21.1", ] [[package]] name = "urllib3" version = "1.26.16" requires_python = ">=2.7, !=3.0., !=3.1., !=3.2., !=3.3., !=3.4., !=3.5." summary = "HTTP library with thread-safe connection pooling, file post, and more." [metadata] # not shown for brevity [metadata.files] # not shown for brevity ``` Perform `fossa analyze` ```bash fossa analyze && fossa test ``` Note: Sometimes with pdm, when you perform `pdm` install, it creates `*.egg-info` directory, which contains `requires.txt`. This may introduce additional dependency in the analysis, as `fossa-cli` will consider `requires.txt` to be `setuptool` manifest. To exclude such unwanted dependencies in your analysis, you can use file to exclude specific paths from the analysis. Here is an example: ```yml version: 3 paths: exclude: ./myexample.egg-info ``` How do I perform analysis for only `pdm`? Explicitly specify an analysis target in `.fossa.yml` file. The example below excludes all other analysis targets: ```yaml version: 3 targets: only: type: pdm ``` How do I include optional and development dependencies in the analysis? You can include all optional and development dependencies in the analysis using: `--include-unused-deps` flag. If you want to only include optional dependencies in the analysis (without development dependencies), currently this is not possible. ```bash fossa analyze --include-unused-deps ``` I have path dependency, would FOSSA analyze it's transitive dependencies? Fossa analysis discraded path dependencies in the analysis, but keeps it's non-path transitive dependencies, in the analysis.