getpelican / pelican-plugins

Collection of plugins for the Pelican static site generator
Other
1.38k stars 849 forks source link

Have a catalog of all the plugins #39

Open almet opened 11 years ago

almet commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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

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

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:

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

almet commented 11 years ago

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 commented 9 years ago

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

justinmayer commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Moved previous comment to https://github.com/getpelican/pelican/issues/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 commented 9 years ago

A little more info on using DOAP files:

naturallymitchell commented 9 years ago

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 commented 9 years ago

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

MinchinWeb commented 7 years ago

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

almet commented 7 years ago

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 commented 7 years ago

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

jorgesumle commented 7 years ago

So... Now we have:

I think that this issue can be now closed.

almet commented 7 years ago

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

Lucas-C commented 5 years ago

Related to https://github.com/getpelican/pelican-plugins/issues/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