It's taken me awhile to wrap my ahead around the pre- and post- Pelican 4.5 plugin repositories and organization. To help others grapple with the Pelican universe I think it would be good make a clearer distinction between the old and new structures.
To that end I've forked the repository and re-arranged in a way that I think is clearer, while still allowing folks who need to use the old plugins to do so with a minimum change in workflow. I'll reference this issue shorty with a PR that shows what I'm thinking of.
One re-org option is to keep a single branch and push plugins into a legacy sub-folder. I decided against that thinking that it would be easier for folks to check out a branch and leave all their paths etc. intact. If it turns out to be the other way around, using a branch is more work than changing a path, I'm happy change the approach.
Updated: 2023-01-24 I'll be editing and summarizing the opening post wiki-style rather than adding streams of comments to myself below.
It's taken me awhile to wrap my ahead around the pre- and post- Pelican 4.5 plugin repositories and organization. To help others grapple with the Pelican universe I think it would be good make a clearer distinction between the old and new structures.
To that end I've forked the repository and re-arranged in a way that I think is clearer, while still allowing folks who need to use the old plugins to do so with a minimum change in workflow. I'll reference this issue shorty with a PR that shows what I'm thinking of.
One re-org option is to keep a single branch and push plugins into a
legacysub-folder. I decided against that thinking that it would be easier for folks to check out a branch and leave all their paths etc. intact. If it turns out to be the other way around, using a branch is more work than changing a path, I'm happy change the approach.Updated: 2023-01-24
I'll be editing and summarizing the opening post wiki-style rather than adding streams of comments to myself below.