Have a catalog of all the plugins

[almet]

Sublime text, for instance, maintains a simple json file hosted somewhere remotely and there is a little command line to list / install the plugins. I suppose we could do this.

It means that each plugin should have a setup.py and proper packaging, but that would also enable people to not depend on this pelican-plugins repository.

Thoughts?

[justinmayer]

@ametaireau, @saimn, and I talked about this on IRC and came to the conclusion that pip + PyPI is probably the best route to go for this, perhaps asking folks on catalog-sig to create a new classifier for Pelican plugins.

Potential downsides:

1. slow installation
2. each plugin has to be packaged for PyPI

Potential ways to ameliorate:

1. put package cache on Pelican server
2. automate packaging as much as possible

For people with really simple plugins, we could potentially even prompt for their PyPI username and password, and then package + upload the plugin to PyPI for them.

[noirbizarre]

I agree: pip + PyPI is the best solution!!

I already published 2 plugins on this model. It allows:

• by plugin issue management
• by plugin testing with Travis CI
• simpler deployment without using git submodules (plugins are normal python dependencies)

PyPI is not slow anymore and you can cache yourself using the PIP_DOWNLOAD_CACHE envionment variable.

I'm interested in a custom classifier for pelican plugins.

To simplify the plugin writres task, maybe you should provide a template project, or, even better, a command generating a plugin project skeleton with:

• a pregenerated setup.py
• a pregenerated README.rst
• ...

Pelican need to have a Wiki page or a documentation listing plugins.

[almet]

I've made the request to have a Framework :: Pelican classifier on the ML: http://mail.python.org/pipermail/distutils-sig/2013-July/021672.html

[naturallymitchell]

@ametaireau: https://bitbucket.org/pypa/pypi/issues?q=trove

[justinmayer]

Thanks, @mitchtbaum. I made a formal request via that channel: https://bitbucket.org/pypa/pypi/issue/238/request-for-new-pypi-trove-classifier-for

If Richard has not responded in a day or two, feel free to post a comment there in support of this initiative. (^_^)

[naturallymitchell]

How about using peru? AFAICT, it would satisfy our needs for both plugins and themes, provide a robust and pluggable solution for future extensibility, and it's written in Python. On top of that, contributors would be able to continue with their existing workflow, safe from any additional efforts with pypi's packaging requirements. It seems like a win win win.

[naturallymitchell]

Moved previous comment to getpelican/pelican#1655

In terms of a catalog, perhaps it would work well for us to have a flat-file database of pointers to each plugin and theme, and even to a DOAP file within them. That way, a Pelican site, possibly running on getpelican.com, on build, could HTTP request that file and XPath query its description, ie https://github.com/edumbill/doap/blob/master/examples/doap-doap.rdf#L10 . We would have nicely manageable version control and collaborative access for updates when people want to add or change references to this database.

[naturallymitchell]

A little more info on using DOAP files:

• Apache Software Foundation on DOAP files
• GNOME GIT FAQ: How do I add a description to the git web view? What is this "blah.doap"?

[naturallymitchell]

Upon further analysis, I recommend against using DOAP files. DOAP is dopey, not dope. :-p

Seriously though, I have 2 reasons: 1) markdown is way better for file-based, structured data entries (ie Pelican's metadata field support), and 2) it overloads a bunch of important pieces of info into a single file and forces stale redundancy with data sources such as README's full description and VCS's latest tag.

AFAICT, in addition to managing our catalog's entries, we need to have each entry's short description and possibly some other metadata. In terms of pulling in this data, I believe this is all possible by identifying where it is naturally stored and integrating Pelican with that data source to pull it out.

For short description, git's own repository description seems like a viable approach. Gitweb and Cgit each support similar ways of exposing it [0][1], and Github seems to use its own proprietary data storage format for capturing this data[2].

0: git push .git/description file
1: Cgit # Adding repositories
2 <form>Description</form> #~~l> div.repository-description

[FedericoCeratto]

Parsing setup.py or as small json file is much simpler, well-understood and requires only standard libraries and formats.

[MinchinWeb]

@almet @justinmayer It's take a bit, but trove classifiers for PyPI have now been added!

[almet]

Thanks! (phew). Anyone wants to hack something together to list pelican plugins / themes out of this? Also, we might want to advertize these somehow.

[MinchinWeb]

You can search just PyPI under Framework :: Pelican...

[jorgesumle]

So... Now we have:

• https://github.com/getpelican/pelican/wiki/Externally-hosted-plugins-and-tools
• https://github.com/getpelican/pelican-plugins
• Framework :: Pelican classifier in PyPI
• https://github.com/getpelican/pelican/wiki/Powered-by-Pelican (where you can find out the plugins other people use)

I think that this issue can be now closed.

[almet]

We still need to advertise this somehow so that People can find the information easily, no ?

[Lucas-C]

Related to #213

@almet : agreed, this should appear in this repo README (with a mention of our policy regarding git submodules) and in Pelican documentation: https://docs.getpelican.com/en/3.6.3/plugins.html

Once those 2 PRs are created & merged we can close this issue I think