Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Survey of Python-vendoring tools #5

Open
2 tasks
sethmlarson opened this issue Nov 4, 2024 · 3 comments
Open
2 tasks

Survey of Python-vendoring tools #5

sethmlarson opened this issue Nov 4, 2024 · 3 comments
Assignees

Comments

@sethmlarson
Copy link
Member

sethmlarson commented Nov 4, 2024

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

  • vendoring
  • vendy
@sethmlarson sethmlarson self-assigned this Nov 4, 2024
@di
Copy link
Member

di commented Nov 5, 2024

https://pypi.org/project/vendy/ exists as well, although I'm not sure it's widely used.

@di
Copy link
Member

di commented Nov 11, 2024

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:

  • A way to declare vendored dependencies in project metadata (something like vendored_dependencies
  • A standard way that tools like vendoring/vendy should bake these into the source tree

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

@sethmlarson
Copy link
Member Author

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants