Plugin Catalog

[shahruz]

I'm currently using https://github.com/sketchplugins/plugin-directory, which is an excellent starting catalog. But I think that some parts of the structure could be improved for use in the Toolbox.

Primarily:

• Human readable names (currently they are all just the GitHub repo names, which aren't ideal)
• A separation of plugins. Many of the plugins in the catalog are actually personal collections, so it can be very hard to determine what you're getting when you download it. I think either the directory or the Toolbox should be responsible for solving this problem by separating each out and providing a description for each.

[bomberstudios]

I'll happily accept proposals for improvements and pull requests in plugin-directory : )

[shahruz]

Awesome!!! I'm going to think through the structure a bit more. Want to make sure it's easy to maintain long-term.

[florianbuerger]

Maybe instead of just one JSON file we can adapt the structure of Cocoapods Specs and host the plugin directory directly on Github. Every plugin developer then have to write something like the .spec file to maintain meta information about his plugin.

[shahruz]

I'm a fan of that idea. Cocoapod's structure also allows for versioning and the addition of new metadata over time. Right now I'm just checking for updates on the master branch of each repo, which seems less than ideal.

Do you think it'd be too much to ask the plugin developers to start thinking about their plugins in this way? In other words, each plugin should have:

• A name
• A description
• An author credit
• A link to a github repo
• Versioning

Seems like if we were to suggest adopting this format, makes sense to do it sooner rather than later... I'm going to have to look into Cocoapods' flow a bit more to get a better understanding. @florianbuerger is that something you understand pretty well? Am I missing anything?

[florianbuerger]

I don’t think it is to much to ask the developers for. This worked well for CocoaPods. And we all want a better plugin platform so users and developers both are the beneficiaries.

I have a lot of experience with CocoaPods on both the pod spec developer site as well as the user site. So if you have any questions feel free to ask. I want to bring the plugin platform for Sketch to the next level so maybe we can have a chat about it’s feature? I am @florianbuerger on all the social networks or we talk in the Slack Designer News chat.

Cheers, Florian

[timuric]

@shahruz not much at all.

Also how about collaborating with these guys || guy http://sketchpack.in/ ?

[shahruz]

The guy from sketchpack emailed me, and I invited him to chime in on this thread.

@florianbuerger I think there might be a time difference between us that makes realtime chat a bit tricky. I definitely want to continue this discussion, either here or via email (me@shahr.uz). I'd be thrilled if you could lead the charge on spec'ing out what a good format would be, since you know the area much better than I do.

I think ultimately this is the biggest problem to be solved..

[ghosh]

I faced the same issue when I was building out http://sketchpack.in/. I opted for the JSON file approach, since mine is purely web based and built on php. It worked out pretty well. Its quite simple to create as well as read and parse.

There is ofcourse the slight friction for the plugin authors, when it comes to creating an extra file in the plugin repo. However, I guess it was necessary as I could not figure out another way to get the data in a clean format.

I guess, one thing which worked in my favour is that a lot of package managers like Bower, Composer, NPM etc. take a similar approach. So I guess people are already used to the idea of the JSON file providing meta data about the repo/plugin.

[florianbuerger]

@shahruz Yeah seems that way. We should continue here so others have the chance to read & discuss, too.

I am happy to throw something together for the Spec. We should collect all requirements the file format has to fulfil, I expect them to be a bit different than the Podspec Format (which is now also JSON based)

I think plugin developer won’t have a problem to write this. Let’s discuss the actual file format in #15

[timuric]

Great to see you guys working together. I would like to add that I think it is in authors interest to provide description file. For instance if you commit readme changes (or readme related files) you don't want to push these changes to the end users, thus you would not not iterate the version of the plugin. Also providing tags is very important for the authors to make their plugins discoverable.

[florianbuerger]

Thanks! I've added a spec and master repo proposal to the wiki. Not sure about the categories yet. Do we use them to filter/search from Sketch Toolbox?

[shahruz]

I think this conversation's become redundant with #15, so I'm closing it off for now to clean things up