I've made something that some of you may be interested in, I've called it the SwiftPM Library and it's a search engine for Swift packages. It's very early days, but I wanted to get some feedback on it even in the state it's in right now.
I know the Package Registry is coming, and it may well kill this little project of mine dead, but also maybe the two can coexist. It all depends on what the Package Registry does when it gets released.
I don't know where Apple and GitHub are planning to take the Package Registry, but I know where I want to take the SwiftPM Library. I'd love to take it in the direction of providing more Swift specific metrics and base search results on those. I've written up much more detail on everything in this blog post.
I'd also like to open up some discussion on another idea I have, for providing additional metadata about packages outside of the Package.swift manifest. I've written a bit about that here and I'd love to get a bit of opinion in that survey, or in comments on this thread.
The very last thing I want to do is try and subvert the evolution process for the Package Manager, but at the same time I'd love to give package authors a way to tell tools more about their packages. Obviously the evolution process is slow (for good reasons), but maybe an additional metadata file like this is a way to test out ideas before proposing them for evolution? I don't know, but I'm listening.
I'd love to know what you think about the SwiftPM Library, and also the idea about extra metadata.
I think that makes sense since the cost of adding APIs in the Package.swift manifest file is pretty high. I would recommend placing this file inside the .swiftpm directory, which was introduced as part of SE-0219:
The configuration file can be expanded to add other information if it makes sense to add it there. Other tools and IDEs written on top of SwiftPM, can also use the .swiftpm directory to store their auxiliary files.
This thread may also be useful for some previous discussion on the topic of providing metadata for a package manager: [Pitch] Adding metadata to SPM Package
If you're looking for feature ideas, some sort of popularity/trending index would be great to see up and coming libraries.
You're probably aware, but I believe Apple announced github will be adding SPM support to their Package Registry. Unsure when that will happen and I hope there will be several viable options for this type of thing, but just to say you'll have a pretty large competitor soon that you'll have to differentiate from
As far as additional meta-data, I would hold off a year or two and see if something "official" is defined. As others have mentioned there are already calls to support additional data, and we all know the pitfalls of competing standards
In that pitch I linked to, it was discussed and suggested/recommended that a 3rd party go out and create their own metadata format and then once it gained popularity then it could be used as a basis for the future official design. I've seen this sort of thing suggested in other places on these forums too rather than pressuring/waiting for the official language to include it's own version. There are a lot of things on their todo list and there are never any guarantees for when they will get around to something.
I do agree with the competing standards thing, but I'm also beginning to realize the very real limitations to the core team's time with regards to reviewing (and sometimes creating) all the features I want, in the order/priority that I want them. Since it could potentially be years before there is anything official I think it would be a great idea to have a 3rd party thing to lean on, which might even end up being used as the basis for the official design.
I realized a long time ago that suggestions like that are largely a copout, as any potential standard will need to go through evolution to be integrated into the Swift tools anyway, so it doesn't really save us anything. It's just a way of saying "We don't want this, but we can't think of a good reason why not. Go do a bunch of work and maybe we'll reconsider." Frankly, package metadata has been well developed in multiple ecosystems, so there's no reason to think a community standard will do anything particularly unique. I'd hate to see Swift come up with a worse solution because of this.
Recommended seems like a strong word based on skimming the topic, but the point seems valid.
Personally I've had enough experiences going down a 3rd party route and then support/development for it being dropped. So I would be hesitant to integrate something like that into my process when it seems inevitable that there will eventually be an official solution. But that's just my opinion that not everyone will/should share
Agreed. My vote is to put it in the package manifest like what both ruby and python do today for rubygems and pypi, respectively.
A perfectly valid position and completely understandable.
I would much prefer to just get it done officially today. However, as there is no guaranteed timetable for that solution and history has shown that people don't agree on how to do it, I personally, support the 3rd party efforts to get a solution sooner.
Perhaps the official solution just needs a motivated individual (or group of individuals) with the time to write a proposal and kick off the discussion and see it through to the end. With there being so many other ecosystems from which we can design a solution (many of them being quite similar), you would think that there wouldn't be a need/desire to differ drastically from those and that this could be a fairly straight forward proposal.
Thank you all for your thoughtful responses, both here and on the quick survey that I put up (I published the anonymous responses here if you're interested).
I don't think there's an obvious ideal solution to this problem. Is there ever?
The benefits of keeping everything in Package.swift are fairly obvious. I think the main one is that having the metadata right next to the package configuration will mean that is more likely to be accurate and be updated when the package changes. Arbitrary extension of that Package.swift file is really not ideal though, and without support for the metadata in the official tools, extracting it is non-trivial.
There are benefits to keeping a metadata file in the .swiftpm directory too. It can't and won't get in the way of anything that touches Package.swift. It's a safe way to experiment, it's what Ankit recommended. The biggest disadvantage of this is that the metadata will be hidden away in a directory only normally accessed by the computer through tools, which makes it much less likely to see adoption.
That said, I think with the support of a tool actually making use of this metadata in a practical way (the SwiftPM Library), it does stand a chance of getting some adoption.
I would much, much prefer to get this done officially too. But after looking into the history of this, and discussing it with several people over the last few days, I think the best plan is to get something together, and build a tool on top of it and see what requirements come out of that.
I'm going to put together a document over the next few days with a draft spec for a metadata JSON file which could live in the .swiftpm directory. I'll come back here for some feedback in a few days once that's done.
Thank you so much again for all of your thoughts on this, I hope we can build something really fantastic out of this.
