Consider vendoring legacy_api_wrap about anndata HOT 3 OPEN

Each dependency brings possible dependency resolution issues (e.g. people pinning it) and supply chain vulnerabilities.

I generally agree that those issues exist (to varying degrees)¹ …

I would suggest that we use a submodule to specifically vendor legacy_api_wrap.

… but those reasons don’t apply to this specific library:

• It’s tiny, tested, and focused on API versioning. It follows semver and there is no reason to release a 2.0 for it.
• There‘s no supply chain issue: It’s controlled by me, so instead of compromising any anndata contributor, I specifically would have to be compromised. So anndata is more vulnerable than it.

I think there are use cases for vendoring, but I’ve been bitten by it more often than I’ve seen it pay out. I haven’t dealt with git submodules in a while, but unless things changed, they also add complexity and make things harder (not only for newbies). So unless there’s an especially good case for vendoring², I’m against doing it, and if there is, I don’t know if git submodules are the way to go.

¹ Except for “people pinning it”: If we need a new feature of a dependency, we bump the minimum version we depend on and people pinning things might need to use an older anndata. That’s why we’re careful about doing that
²small, many people with PyPI push permissions, used by many projects, several major version updates or breaking changes.

from anndata.

Conda has a policy against vendoring, so let’s not do that.

• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).

from anndata.

How do they handle scipy? Or versioneer?

from anndata.