Author’s overview

[wadetregaskis]

It’s not a revolutionary thing, but it would be pretty neat if there were a way to view an overview page for a given package author, which shows in brief their list of packages, what Swift versions each builds on, what platforms, and other such core details. Perhaps have some kind of matrix / table.

That would make it extra easy to utilise the Swift Package Index’s awesome build and test suite to keep tabs on all my packages (especially if and when SPI starts auto-rebuilding packages when their dependencies change).

Perhaps this is a simple evolution of the existing author page.

[daveverwer]

Thanks for the kind words, Wade, and for the interesting idea. However, I'm not sure bringing the matrix in to the author page is quite the right approach, both from a query performance perspective (for users with a great many packages) but also from a UI perspective.

It is the kind of feature that would be great if limited to the author, though. I still have a desire to implement some features behind some type of authentication process, and this kind of "How are my packages doing with compatibility?" idea would fit better there. The big problem, and the main reason we haven't tackled anything like this yet, is that of package ownership.

The most logical auth to use would be GitHub login as access to a GH account means access to the packages, but that ties the site even more closely to GitHub, and we do still want to keep the door open to supporting other source control providers, even if it's not something we're working on directly right now.

Certainly some food for thought in your idea, though! Thanks for submitting it and we're happy to keep discussing it, this is not be shutting down the possibility!

[finestructure]

One of dealing with at least the notification part of this in a more general way would be to add a field like notification_contact to .spi.yml. We could use this to alert whoever is configured as the recipient about various things (changes in the support matrix, doc build issues, at some point perhaps even CVE alerts in dependencies).

Using the .spi.yml file ensures it's platform agnostic but also under the package authors' control.

[daveverwer]

I almost mentioned this in my reply, but there's another thing we could do in a similar vein to the .spi.yml, but at an author level is a repo that contains configuration for the author/organisation. Clabot does this to let you set a policy across all repositories in an organisation.

One thing that works against this is discoverability. We have the "Information for package authors" page, but having an authenticated section of the site for an author gives us so much more in terms of showing authors what's possible.