is it possible for a package author to just declare the real dependencies, like through this .spi.yaml file i keep hearing about?
It would be possible but we want to use that file to steer how we process information, not to be an override for the source of truth. It would be too easy to have it drift from the actual settings in the manifest or repository. It would also make it very easy to inject wrong information into the index.
since we can’t really show any information about why the dependency count is so high
Well, you’ve got the README, which we’re displaying prominently just below the top section :)
We'll also be adding more dependency information in the future, such that people browsing for packages can inspect what the actual dependencies are without having to drill into the package manifest.
or even that the dependencies are maintained by the same author
That is certainly information we could take into account when expanding the dependency info section.
it sounds like the only solutions here are to either:
- “flatten” the repository and include the plugins as a submodule or directly in the repository, or
- use build flags to disable tests + doctools by default.
in the long run, i think it will also encourage large monolithic frameworks like in the early days of swift, instead of the more atomized, modular system promoted by the SPM.
Well, all we can do is surface the information that’s there. We can make it easier to inspect what the dependencies are but absent any further semantic information what they are for we can’t really make any distinctions that I can see.
Can you think of ways to discover that which would scale across 4,500 packages? The only way I could see this working is if SPM left more details in Package.resolved
or swift package show-dependencies
for us to ingest.
There’s certainly one thing that would be gained if you were to “hide” a dependency from the Swift Package Index via build flags: default operations wouldn’t be (as) susceptible to supply-chain attacks. So in that regard one could argue that’s a good outcome.
Personally, I feel like optimising for zero dependencies at all cost isn’t a healthy goal either, for the reasons you outline. That just leads to less well-maintained copies of logic. And so I don’t think we should go out of our way to make that a golden standard unless it actually reflects reality.
I think if your package has one or two dependencies you’re already in a good place. If potential adopters then see that they're by the same author and one is a build plugin all should be well.
We’ll want to make that information easy to see for users. I think that’s a better outcome overall.