We envision educators and community influencers publishing package collections to go along with course materials or blog posts, removing the friction of using packages for the first time and the cognitive overload of deciding which packages are useful for a particular task. We also envision enterprises using collections to narrow the decision space for their internal engineering teams, focusing them on a trusted set of vetted packages.
Are there further or more concrete motivating examples you could share and/or is there precedent for this sort of concept in other languages/package managers? I feel like this introduces a lot of surface-area and finicky behaviour that wouldn't really be all that useful in the examples mentioned. So far I'd be -1 on this.
For a blog post or course material, as a reader, I would rather have some lines I can copy directly into my package manifest, or just package names and versions, than going through the multi-step process of adding a package collection, getting the details for each package from the cli, filling that into my package manifest, and then possibly removing the package collection again.
As writer, including a list of packages with my content directly also makes sense. It allows me to introduce packages at points in my content where they are relevant (think a list of packages per assignment, rather than a big collection for the course that readers have to find their own way through, which sounds horrible for students in particular; I wouldn't want some confused student to implement some big functionality themselves because they didn't think of the right keyword to search for), I can provide additional information about the packages without breaking the flow of my medium, and it means I don't have to worry about having to somehow produce a JSON file of unknown format (as far as the proposal goes), and—this applies to course materials more than blogs—host that somewhere, hopefully somewhere that doesn't go away and render the content harder to follow in the future, maybe as soon as next semester.
Consequently, I don't really see how introducing a package collection would remove friction in using packages in these examples. Writers and readers alike would need to know both what they currently need to know about how swift packages work, plus how the package collection concepts and commands (and JSON format) work, and the process involves more steps when using a package collection compared to including package lists inline.
The list of vetted packages to be used in an engineering team I think is the strongest example here, although to be a full solution, some more tooling to verify that only packages from a particular collection are used in a companys projects would be required. I also think this example is hurt somewhat by the proposed limitation of only having the latest patch version in each major-minor-combination includable in a collection, because it kind of bypasses the vetting aspect.
Apart from motivation, I too would like to see metadata fields and the format of collection and configuration file mentioned in the proposal, and I think the configuration system is needlessly complicated. Templating of configuration files and provisioning of machines configured for specific users is best handled by one system for all tools rather than by each tool on its own. Plus the choice of the git config file format confuses me. Is this supposed to include things like include and includeIf? onbranch? Does any of the type system from git config apply? Is there good tooling to parse and manipulate git config format files in popular languages? I think something like a simple INI format, or TOML maybe, would be more appropriate, but like I said I don't think this supplemental file is necessary at all. (Also, maybe ~/.config/swift/pm as directory, to have a nice place for other swift toolchain configuration?)
Lastly, the future directions section I think should elaborate on how in particular this proposed feature would integrate into "[f]uture work to support more dynamic server-based indexes". If this is to be a foundation for some bigger feature, I think it should be reviewable in that context (and maybe pitched together with that bigger feature as well).
on