Support setup.py in Dependency Scanning
Problem to solve
Right now (AFAICT) dependency_scanning requires a project to have a requirements.txt present. However, requirements.txt doesn’t make sense for all projects (e.g., libraries) to have since they don’t need the absolute dependency resolution but can make do just fine with the relative dependencies as given in setup.py.
Intended users
Further details
Python support for Dependency Scanning is implemented in gemnasium-python, which only supports pip and pipenv at the moment.
In main.go, gemnasium-python detects the PackageManager, then delegates the installation of the dependencies and the generation of the dependency graph.
Proposal
Create a new package manager handler in gemnasium-python:
- update gemnasium-python
- create a new package manager handler
- create a new Go file in pkgmgr
- declare a Go struct implementing
PackageManager - implement
InstallDependenciesby callingpython setup.py - reuse code from pkgmngr/pip.go to generate the dependency graph
- change the detection logic implemented in NewPackageManager, return the new package manager handler when there's a
setup.pybut no file pip or pipenv can handle - change plugin/plugin.go to respond to
setup.py - optionally, introduce a plugin architecture for the package managers
- iterate and delegate in plugin/plugin.go
- iterate and delegate in NewPackageManager
- publish new release
- create a new package manager handler
- update dependency-scanning
- update Go dependency
gemnasium-python, so that Dependency Scanning responds tosetup.py - publish new release
- update Go dependency
- create new test project, or add specific branch to existing one
- update GitLab documentation
Permissions and Security
No changes to current behavior.
Documentation
Documentation should be changed to denote that setup.py will be supported in addition to requirements.txt.
Testing
It needs to test correct behavior in cases where more than one of setup.py and requirements.txt exist and possibly give conflicting dependency information. (requirements.txt being the description of a full environment at a specific version should probably take precedence, followed by whatever order of setup.py that pip does.)
What does success look like, and how can we measure that?
Success would be that a project that has a setup.py specified but no requirements.txt is still able to utilize the Dependency Scanning CI security feature.