Open sethmlarson opened 2 weeks ago
https://pypi.org/project/vendy/ exists as well, although I'm not sure it's widely used.
Thinking about this a bit: given that there is no standard for vendor-ing and that these two tools are not widely adopted, I think there's possibly a number of projects with vendor-ed dependencies might be missed by any SBOM standard.
For example, if a project is just copying one source tree into another and publishing it, this is exactly the thing we'd want an SBOM for: SCA will likely miss this, there's nothing declared in metadata about it, etc. But the project has no real incentive to do anything differently because there is no standard.
Given that, I wonder if it makes sense to pursue a standard for the use case that vendoring/vendy cover. Specifically:
vendored_dependencies
Feedback I've gotten before is that "fat distributions" isn't a use case we generally want to encourage, but the fact that these tools exist and that projects are likely vendor-ing other projects without using them as well leads me to think that it would be worthwhile (and would mean that any SBOM tool would not have to understand N different ways to vendor dependencies).
@di Indeed, I've seen vendored Python dependencies used pretty frequently especially in the packaging space. Another future I could see is for one of those tools to become more widely adopted in projects where folks are vendoring dependencies.
I'm interested in seeing if there's a way to "detect" vendored projects, I used license detection as a part of my work on CPython's SBOMs to find bundled dependencies. Maybe that is effective here, too?
pip uses a project called "vendoring", it should be fairly straightforward to add SBOM generation to a project like this especially because the results live in the source tree (rather than being gathered at build-time).