I was always curious about Swift package manager.
What I expect from a "package manager" is something like npm/pip for node/python
But I feel like SPM isnt like them.
I feel like SPM is much more complicated and hard to use. There isn't even a browser like:
And even Dart has one (https://pub.dartlang.org/)
Is is because all they are dynamic scripting language and Swift isn't?
or is it because Swift is not mature enough?
No.
Yes. There are some related ideas in these threads:
Is it mostly an index you miss?
We generally agree, I think almost all of us believe that SwiftPM should have an index. However, the construction and engineering of a such a thing is very non-trivial. We chose to get started with a distributed model to avoid the need to build an index, and hope that we could add an index later.
I definitely agree that not having an index makes SwiftPM much harder to use than I would like...
The construction and engineering of package indexes has been done a dozen times by now, so while the resources needed may not be trivial (though close, given the capabilities of modern cloud hosting), saying the engineering would be hard is a cop out. It's just that Apple hasn't prioritized it and seems organizationally incapable of hosting good developer web services anyway. Frankly, the index is one of the reasons that I think there should be a Swift Foundation that runs things like that, as I don't think Apple can be trusted to do so.
The difficulty is not on the hosting, I agree we could sort that out.
I really do think it is on the engineering of the index technology itself. If you are interested in collaborating on the building of an index, patches are welcome! So far, we haven't had people signing up to work on this area, and there are plenty of other areas that need development.
Why would anyone sign up for a part of a project which doesn't really exist yet? Has there been an announcement I'm not aware of? What exactly would be collaborated on, and what would patches be against? No one's going to add index support to SPM until an index is announced and a plan is in place. And like you said, the index is the hard part, integration into SPM is relatively trivial.
Once upon a time IBM had an indexed catalog for SPM. They deprecated it eventually.
Today, we announce the deprecation of Swift Sandbox and Swift Package Catalog, to take place in January of 2018. While both bolstered server-side Swift adoption and experimentation, previewing Swift on the server in this fashion is no longer required.
making the index isn’t hard, getting people to use the index is hard. many swift package indexes have been made, you just never heard of them because they never gained community traction. the IBM one is one of them, there was another one I found a while back but forgot the name of. here’s another example: https://swiftpack.co/
The second one was called Swift Modules. It died a few months ago.
Jon, you've made your point that you're unhappy that this isn't done already. All you're doing here is saying "it should be done already" more and more angrily. Please don't do that.
Sorry if that's how I came across. Mostly I'm disappointed, but I was a little angry at @ddunbar's suggestion that the reason a package index doesn't exist is because the community hadn't suggested it or pushed it. So while I certainly believe an index should've been one of the first things developed for SPM, that's not really my issue at this point.
Fundamentally SPM, and a package index in particular, suffer from being one of the few core bits of Swift that doesn't seem to have a manifesto or other feature outline guiding its development. That means when threads like this come up, we can't just point to the manifesto and say "It's coming eventually!" like we can with language features. It also means there's no point of attack for community proposals. So what I'd like to see is an official acknowledgment from Apple / the core team that a package index is a useful and important part of the Swift ecosystem and that it will be built and supported as soon as resources are available. That would provide at least a little reassurance to those Swift developers that believe, like I do, that an index is a key part of Swift's long term viability.
If an index is something that the core team / Apple wants and thinks can be supported, and if community input is desired, it's important to lay out the parameters under which such a service must exist. Once that occurs I'm sure a variety of community members would be glad to contribute.
Thanks for your explanation Jon, I can certainly see your perspective.
From my perspective, I tend to favor what I regard as a more agile, incremental approach -- I think it isn't necessarily a good use of time to lay out parameters or attempt to scope a project for which there aren't actually engineers available to work on.
It is certainly fair to debate what the project priorities should be, I think one could argue that an index is more important than some of the other things we are doing, but that is a different discussion. Ultimately, though, this is an open source project and if you feel the project direction is wrong it requires showing up with a proposal (and usually an offer of help) to impact the direction.
To be clear, when I say "index" I do not mean something like IBM's "Swift Package Index", which was just a catalog scraped off of GitHub.
I mean a deeply integrated system which allows SwiftPM to easily find packages by name, provides facilities for developers to publish packages, and so on. Comparison systems are things like NPM, Cargo, and PyPI.
My issue isn't so much that the resources aren't there or the the feature hasn't been prioritized. And an incremental approach would be fine, as simple additions to the SPM package definition and simplified features of the index itself are a great first approach. I just don't think it's reasonable to expect the community to contribute into a void here, which is what happens when there's no real acknowledgement that an index should and will happen. I think it's similar to the non-standard library question where not having a definition of what that even means or even whether it's something that's wanted by the core team prevents people from spending the effort needed to design the feature. It's the same thing here: without knowing that it's something that's wanted and what limitations may be placed on implementation (if it's hosted by Apple I'm guessing Apple legal will be gumming things up, which is another reason a foundation should run this stuff), you'd be hard pressed to find community members willing to spend the time defining such a feature when it could easily fall into a black hole. It's much the same problem Apple's bug reporting system suffers. Once that support is there I think a first version of an index could be defined pretty quickly.
You actually bring up a very good point. Almost every other important part of Swift has a manifesto of some sort declaring the goals, commonly rejected items, etc. I wonder if we could get the @core-team to actually work on one or if someone should write a proposal for it. It would be nice to know that there are definite long-term goals for SPM.
This is actually not true (at least partially), there was a "Submit Package" button (or something similar) where you would give it the URL and name of your SPM package and then it would scrape your repo to get the README and other info. I know because once upon a time I used that button to add a few of my own packages.
Aside: the core team doesn't write manifestos. Anyone can write a manifesto; sometimes the people who do happen to be on the core team, but the manifesto is part of their day-to-day, non-core-team work. We do like for manifestos to actually present the project consensus to a certain degree, and accordingly the core team does like to review them before they're "published", but it's not the core team's role to dictate design work.
Anyway, I think having a public roadmap of where swiftpm wants to go over the next few years is a really great idea for a lot of reasons — and frankly, these apply to all of our subprojects, and we should maintaining similar roadmaps for all of them:
Of course, the community has to understand that a "roadmap" can't be a firm commitment to deliver features on any particular schedule, but we're all software developers here, and we should all understand the difficulties in making that kind of commitment.
FWIW, we do have a post that lists the features needed in SwiftPM for the foreseeable future. However, it doesn't say anything about the priorities.
This would definitely be a good starting point for a manifesto. I may start an evolution discussion to start drafting an SPM manifesto tomorrow and will definitely use it as reference.