[swift-evolution] Large Proposal: Non-Standard Libraries

[Félix Fischer]

I didn’t reply to all before... um,

That’s a very good point.

Still, I’d like the rules to be as clear as possible. That only helps :)

Another point I forgot to mention, Kelvin: Jazzy (
https://github.com/realm/jazzy/blob/master/README.md) derives documentation
from the comments. We can use that in the index :)

On Tue, Nov 7, 2017 at 6:18 PM Kelvin Ma <kelvin13ma at gmail.com> wrote:

> On Tue, Nov 7, 2017 at 3:15 PM, Félix Fischer <felix91gr at gmail.com> wrote:
>
>> On Tue, Nov 7, 2017 at 5:24 PM Wallacy <wallacyf at gmail.com> wrote:
>>
>>> The Compatibility Suite is a good start, but I agree that something a
>>> bit more centralized has its benefits.
>>>
>>> To be perfect, Compatibility Suite and Swift Package Manager need to
>>> work "together" to offer something simple like nodejs npm and a friendly
>>> (and central) interface to not only find these projects. Something more
>>> similar to nuget too.
>>>
>>> The only thing I miss using npm and nuget is some kind of "compromise"
>>> with maintenance. And also some commitment to (avoid) rework. Several
>>> projects remake something that another does also without explaining well
>>> the differences between them.
>>>
>>> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
>>> project like Compatibility Suite with steroids. Not only to track those
>>> projects, but in some level help defining some standards, documentations,
>>> versioning etc. This can be done entirely within the community.
>>>
>>> Not so similar, however the gstreamer keeps a list of "base", "good",
>>> "ugly" and "bad" plugins for similar reasons.
>>>
>>> We can do something in this line of reasoning:
>>> - A central repository for projects (like Compatibility Suite)
>>> - A tool to find and add each project (like SwiftPM)
>>> - Rules for joining (like Compatibility Suite)
>>> - A classification for each repository (like gstreamer)
>>> - A good way to make each project as small and direct as possible (to
>>> take advantage of cross-module inlining / specialization)
>>> - A list of discussion (or a forum?) for people that maintain (or have
>>> an interest in maintain) projects in this "official" list.
>>>
>>
>> I like this approach much more. Feels more natural. And a forum
>> (piggybacking on the eventual Discourse perhaps). I’d only change two
>> things and extend one:
>>
>> - Instead of “central repository”, a “central index”. It makes it more
>> transparent, more distributed, and closer to the current reality.
>>
>> - Here:
>>
>>
>>> I vote for empowering SwiftPM and Compatibility Suite instead a
>>> "Non-Standard Libraries".
>>>
>>>
>> I agree with a central index, but as Kelvin says, we shouldn’t be using
>> the Compat Suite directly because of GPL issues.
>>
>> - I’d extend on the “Rules for Joining” point: they should be as clear
>> and explicit as possible, to avoid drama like the one episode that happened
>> last year on the JS repositories with that string-padding library. That
>> thing broke half of the internet for some hours, and it was all about
>> something unclear in the rules, if I remember the case correctly.
>>
>
> I think Swift is less vulnerable to that than node.js if anything because
> Swift is compiled ahead of time so someone removing their repo doesn’t
> instantly break everything else.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171107/18a9bf5a/attachment.html>