FOSSA supports Python projects through
|Tool||Repository Scanning||CI/CD Scanning|
When Python code is imported, FOSSA will find and run any
setup.py files and recursively traverse dependencies that are brought in via the
If there are any
requirements.txt present, FOSSA will also resolve those entries and treat them as direct dependencies. Sub-dependencies of packages brought in from
requirements.txt are ignored, as consistent with standard build behavior.
Requires Standard Conventions
FOSSA currently assumes that Python codebases using Repository Scanning are following proper conventions where running
pip install -r <requirements.txt>is expected. If
setup.pyfiles are heavily customized or require non-standard versions of Python, FOSSA may fail to run and analyze them.
CI/CD Scanning relies on
fossa-cli v0.5.0+. To get started, install the latest release of
fossa-cli from our GitHub releases page:
curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install.sh | bash
CI/CD Scanning for Python,
fossa will rely on you maintaining an updated
requirements.txt file. This can be achieved by running:
pip freeze > requirements.txt
We recommend you do this as part of your build process after running your
setup.py and within your
virtualenv if necessary.
Afterwards, you can run
fossa and the client will analyze your
requirements.txt and submit dependency data back to [app.fossa.io].
View extended documentation [here].
Complex Builds Supported
For complex Python builds that rely on custom tooling, scripts or virtual env, CI/CD Scanning is the ideal integration path.
You can configure FOSSA to fetch dependencies from private PyPI registries published through tools like Artifactory or Sonatype Nexus.
In order for FOSSA to reach private feeds, go to your Python Language Settings under Account Settings > Languages > Python and add your login credentials.
Now you should be able to resolve private PyPI packages in FOSSA.
FOSSA supports most standard ways Python packages can be included, ranging from packages on PyPI to packages stored in archives / VCS hosts.
When possible, FOSSA will seek source code formats over binary/archive formats like
.whl. If an egg or wheel is downloaded, its contents are inspected for code auditing and dependency information.
- dist-info directories are currently skipped.
- Mercurial, Subversion, and Bazaar Version Control Systems are not supported.
- Source code distributed with XZ compression is not supported.
- Custom build scripts (i.e. fabric, make, etc.) are not supported.
- C Extensions are not supported.
Updated 8 months ago