On replacing packages.json
with ….. something else
#1345
daveverwer
started this conversation in
Ideas
Replies: 2 comments
-
Given the direct tie between SPM and GitHub, you could use GH auth to verify if someone has write access to the corresponding repo and use that for a simplified version of trunk on the web |
Beta Was this translation helpful? Give feedback.
0 replies
-
Yep, that's one way to verify package ownership. I don't see package removal being a huge issue, but it's one we certainly have to consider. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This has come up a couple of times today, and I wrote a fairly long answer with some of my thoughts on the SPM slack. I thought I'd include it here so we can have a record of the discussion around this issue.
I’ve put a lot of thought into the
packages.json
approach, and I’d certainly like to make it easier than it currently is. There are a couple of critical issues, though.Ownership of package records is the main one. The last thing I want to do is to have people need to create/login to an account to add a package. Not only is it a pain, but it then means that one account “owns” the submission of that package to a repository. I want anyone to be able to add any open-source package, without necessarily being the author of it. The problems flowing from ownership of package records are hard to solve.
So that leaves a “drop box” (not Dropbox 😂) type approach. A simple text field on the site somewhere that people can drop a URL in, and we discover the
Package.swift
, validate it and index it from there. That’s OK but leads to issues with people wanting to clean up/remove packages. For example, Tanner just submitted a PR that cleans up a load of the Vapor packages as well as adding new ones. Deletions are hard to do without ownership. There’s the possibility of adding a “Feedback this package” button, but that’s not as easy as a PR as soon as it’s more than one package.I’d also like to make the system more able to discover packages through following dependencies. For every package we have, any dependencies could lead to packages that we don’t have.
For now, a master list is a “good enough” solution. It’s spam resistant, avoids the ownership issue as anyone can add/remove any packages at any time. I do want to tackle it better though
As a bit of a summary. I think the current system is far from ideal, but I'm also not convinced it's a high priority for right now. I think there are areas of the system where our time can have a bigger impact than fixing this.
Beta Was this translation helpful? Give feedback.
All reactions