A few days ago GitHub announced a new product: GitHub Packages: Your packages, at home with their code · GitHub
There is not much I want to say now, but wouldn‘t be great if GitHub‘s Package Registry would also officially support Swift Packages?
GitHub already communicated that the currently supported package types are just the beginning.
What does the Swift community and the core team think about this idea?
I don’t think we need a registry but it would be nice to have a way to search packages like in crates.io but for swift.
The ibm folks had a package catalog thing but that went away.
https://developer.ibm.com/swift/2017/12/07/package-catalog-sandbox-deprecation/
It is unfortunate that the community still fragmented over package manager standard. It would be awesome if all of them used the same layout and configuration files.
https://www.codementor.io/blog/swift-package-manager-5f85eqvygj
I‘m confused by this comment, as it reads contradictory to me. You‘re saying that you don‘t want a registry but in the next moment you‘re linking a registry for Rust packages and saying that you want a package search. To have such a search you need to registry or have some kind of a crawler, former is better than latter.
I think it does not hurt anyone if GitHub would support Swift packages out of the box. That‘s why I‘m surprised that you wouldn‘t want official support for Swift packages.
To be clear, I did not say in the original post that we need a standalone Swift packages registry, but that GitHub‘s new package registry should support Swift Packages, which will give you search functionality for free.
Maybe creates.io is a bad example. I was thinking more like https://chocolatey.org that doesn’t host nugget packages but lists them for search.
I don’t see any reason why not to have Swift work with Github’s registry. I think having a separate index will still be useful, but both can exist.
In general, I hope we can make an index good enough (and soon enough) that it be the normal place to look for packages, and not fall into a trap where the Swift ecosystem revolves around one code-hosting company.
I am a huge +1 to this, it was my first thought when I saw GitHub’s announcement as well.
If the Swift PM team designed and published a registry protocol anyone could host a package registry (including GitHub), I would love that. Unfortunately, I don't see any interest in moving in that direction.
In any case, having decided to use Swift as the language for the package manifests means that crawling, correctly parsing and generating a package database like crates.io does would be a lot more complex.
It is incredibly simple if you link directly against the package manager†. The only restrictions are:
†Or even simpler with the convenience methods in this package, at least until they get sunk into the SwiftPM package itself.
Package management has been one of my biggest pain points with Swift, so I think this would be ideal. Rust did this really well. They have a similarly anaemic standard library to Swift, but at least it's easy to get fetch third party packages.
The fragmentation and decentralization of SPM/Carthage/Cocoapods is really damaging the ecosystem.
Honestly, I don't even know how to use SPM. It doesn't seem to be compatible with Xcode, so I have absolutely no idea how you're intended to use it. Is it for server-side Linux only? What about Apple development, which is the vast majority of Swift's use?
That’s OK for parsing trusted packages on your local machine. But crawling thousands of packages would mean that a server would have to run all the untrusted Package.swift (on Linux there is not sandbox support, so your proposed idea would mean arbitrary code execution). Also, there are a lot of manifests out there with #if ... #endif blocks which cannot be parsed correctly.
Rust TOML package manifests are easily parsed without requiring to run them through any complex compiler. I seriously think that choosing Swift as a manifest language was a terrible mistake and I hope they realize that.
I do not want to derail the thread with my reasoning, but I do want to briefly say one thing for the sake of the package manager developers eavesdropping on us right now: I am very happy about their choice of using Swift itself for the manifest format. Over the years it has proven itself vastly superior to YAML, TOML, JSON or XML approaches, at least in my experience.
But back on topic and with respect to the security concerns, there is nothing stopping a higher‐level crawler tool from doing sandboxing of its own. (Or its author could submit a pull request to SwiftPM with that fix so everyone benefits.)
Shameless plug. I did create an API that uses GitHub's GraphQL API to search for SPM packages. The code is opened-sourced. You can access it at https://package.vapor.cloud/.
There isn't a front-end at this point, but it can be useful if you create a tool that accesses SPM packages.
Yes, and IMHO this also leads to people wanting to add everything and the kitchen sink to the stdlib, instead of delegating certain tasks to libraries.