search

pelican-plugins / jinja-filters

Jinja Filters is a plugin for Pelican, a static site generator written in Python.
MIT License
5 stars 2 forks source link

Transfer repository to Pelican Plugins organization #3

Open justinmayer opened 4 years ago

justinmayer commented 4 years ago

@MinchinWeb said:

Would it be possible to "transfer ownership" instead?

The advantage of this is that is moves everything (issues, PR history, forks), and not just the Git history.

To do it, you'd need to give me permission to create repositories under pelican-plugins.

Done! Once you accept the invitation and this repo has been transferred, I'll rename the repo such that it lives at pelican-plugins/jinja-filters in order to maintain consistency with plugin naming conventions throughout the new organization. Looking forward to collaborating with you over at the new communal org! ✨

MinchinWeb commented 4 years ago

@justinmayer The plugin has arrived!

I renamed it before moving it over, but you'll have to trade the underscore for a dash.

I also moved over my No Jekyll plugin. My other plug-ins seem to be pulled from the pelican-plugins repo. Should I move them here, or would it be better to re-extract them from the "main" repo? These are the ones in question:

I'll work to get out two new releases of these plugins: one ("version 2.0.0") that is in the pelican.plugins namespace, and one on the existing namespace that imports from the new namespace.

For plugins in the new namespace, is there a standardized naming structure for PyPI? Should I push the plugins to PyPI, or is that something you want to manage?

Thanks for helping make sure this happened!

justinmayer commented 4 years ago

@MinchinWeb: Thanks for transferring the repo over here. Awesome!

Let's try migrating & updating one plugin at a time until we establish some migration flow rhythm, after which we can move on and do the same for the other plugins.

you'll have to trade the underscore for a dash.

As you can see from other repos under the new org, the goal is to maintain some degree of consistency across plugins, so I have taken the presumptuous liberty of changing the underscore to a dash. If there is a specific reason for it to be an underscore, by all means please let me know.

I'll work to get out two new releases of these plugins: one ("version 2.0.0") that is in the pelican.plugins namespace, and one on the existing namespace that imports from the new namespace.

I'm not sure I follow the rationale here. Could you elaborate?

For plugins in the new namespace, is there a standardized naming structure for PyPI?

There is indeed a standardized naming structure, which is automatically generated by the Cookiecutter template. I'll push up a PR shortly with some proposed changes.

Should I push the plugins to PyPI, or is that something you want to manage?

That's best handled by the same GitHub Actions + AutoPub flow that we are using for the other plugins under the new organization. I'll include that in a separate to-be-submitted PR.