How to List RubyGems(.org) Jekyll Plugins

[Parker Moore]

I think this site has potential to be a great place to discover gemified Jekyll plugins. The potential I see, however, does not mean it can actually be useful and therefore that we should use it. Any thoughts on this?

[Parker Moore]

@benbalter @gjtorikian I wrote up this site (it took me like 15 minutes so don't hate on my design plz) in order to offer a way for plugin writers to market their plugins. Do you have any ideas or spare brain cycles to maybe flesh out a design or hack on a nice search method (like a big table that you can search through via a text field?), etc for this site? Encouraging a vibrant ecosystem is something I'm all for, but I'm not quite sure how to approach this problem from a user perspective.

[Garen Torikian]

I want this to be A Thing. I think before starting to discuss what it should look like and how it should interact, we should talk about how it should be populated.

In my mind, lowering the barrier and making it a repository makes getting this up and running way easier. Forget doing it in CouchDB or whatever: authors can make a PR here to get their plugin listed.

How should a plugin be listed? Well, we could mandate the inclusion of a package.yml file that has some keys it must have, and some keys it should have. Must keys include:

• Name
• Type (Generator, Converter, Tag, or Ruby gem)
• Version
• Author

Should could include:

• Description
• URL to project
• License

We can enforce these from plugin authors by writing a test and validating the PRs through Travis.

From the description, title, and category, it should be possible to construct some JavaScript "search.json" file that would power the search, via lunr.js or something. At that point I'd start thinking about what it should look like.

This is all my 10.30 am pre-:coffee: ideas, though. It would be really nice if we could tie into the RubyGems API somehow, to show how many people have downloaded a plugin, e.t.c.. It's not impossible, I'm just not sure how you'd fetch a list of Jekyll plugins from RubyGems (if they gem has "jekyll" in the name? That seems very prone to error).

[Parker Moore]

@gjtorikian Thanks for weighing in! Agreed, we should definitely think about what kind of content we want on the site before getting ahead of ourselves.

I think we MUST have a

• Name
• Type (Generator, Converter, Tag)
• Version
• Author
• RubyGems URL (are there other hosts?)

The type could eventually be encapsulated each as a Collection in the new 2.0 model, once that lands.

The reason I add the RubyGems URL to the MUST is that we want to encourage shipping plugins as gems, for the myriad benefits it gives users and developers alike. Shipping as a GitHub repo is really not recommended, and we need to be clear on that. Additionally, we wish for the flexibility to call our plugin jekyll-sass on rubygems.org but want it to be listed as Sass Converter on plugins.jekyllrb.com, such that plugin name != gem name Whether or not we should allow for this difference is mostly about what lends itself best to discovery and will seeing jekyll in every plugin name be more noise than we are cool with?

We could offer the SHOULD options you describe above as well.

@qrush, is there a nice way to go about finding Jekyll plugins on RubyGems.org other than using the API to search the term jekyll and going through them by hand?

[Nick Quaranto]

There's really not an easy way right now. This could be done via metadata though...and exposing a new endpoint to query for plugins. This would be pretty useful for RubyGems plugins themselves too. /cc @drbrain

Sent from my iPhone

[Garen Torikian]

This could be done via metadata though

If I'm understanding correctly:

• Jekyll authors add s.metadata to their gemspec, indicating it's for Jekyll (:jekyll => true or whatever)
• Metadata is exposed through the RubyGems API to retrieve this

That'd be great. Sounds like it'd put some work/pressure on RubyGems though (i.e., implement the API, reindex all existing gems to collect information, e.t.c.).

[Parker Moore]

Another idea: can we collect all gems that require jekyll as a runtime dependency?

[Matt Rogers]

You can do that locally using the Gem::Specification API, but I don't know how if there's a way to do it remotely.

[Nick Quaranto]

Just had this idea randomly: what if there was just a Homebrew style repo where people could submit PRs to, and it could list their gem? Then the site can just read that in. Added bonus: removed dependency from rubygems.org ;)

Sent from my iPhone

On Jan 17, 2014, at 9:23 AM, Matt Rogers [e-mail] wrote:

You can do that locally using the Gem::Specification API, but I don't know how if there's a way to do it remotely.

—
Reply to this email directly or view it on GitHub.

[Parker Moore]

@qrush That's what this repo is meant for. I'm wondering how we go about populating it with a useful list initially.

@cobyism, @jglovier If you have any design ideas (even a rough sketch) as to how you think this site should look given its purpose, i would love your input! My design skills are not so good... :)

[Garen Torikian]

We could use the GitHub Code Search API to index / represent the package files through the plugin site. That might make the most sense in the short term (rather than run a full indexing / search service elsewhere).

[Parker Moore]

@gjtorikian Initially, I'm 👍 on that as a means of populating the site. I think @qrush is right though – it should be a Pages site. A PR is a pretty low barrier to putting your plugin on our site.

[Garen Torikian]

Oh, it can still definitely be a Pages site. We can just use the Javascripts to do a GET against the Code Search API. Let GitHub do the indexing of the plugin metadata file, and set the search bar to just execute <query_string> extension:yml path:plugins_folder or whatever.