investigate utilizing cookiecutter

[dreamalligator]

the primary clunkiness as brought up in getpelican/pelican-plugins#425, is that someone using this project would have to manually replace all the lines that are thedropin specific.

v2 should have some convenience scripts, or utilize cookiecutter to set up all the necessary bits.

• https://github.com/cookiecutter/cookiecutter
• https://cookiecutter.readthedocs.io/en/latest/

[justinmayer]

Hey Tommy. Nice work! Since I posted my comment yesterday, I've actually been working on a CookieCutter template, the initial version of which I just pushed: https://github.com/getpelican/cookiecutter-pelican-plugin

Still very bare-bones, but it's a start.

[dreamalligator]

awesome, I'll check it out :D

[dreamalligator]

@justinmayer would you like to add your changes to this repo? we can rename it something more pelican-like. I see you favor BSD license, and probably want to use autopub, etc. Those are things I'm not opinionated on. I'm also open to putting this under the getpelican realm if you'd like?

edit: alternatively, I could see this being a nice parallel if you're not into that idea. I see you're using pipx instead of pipenv and such. That way there are even more examples for the community. ¯\_(ツ)_/¯ thanks for taking a look at this :D

[justinmayer]

Hey Tommy. I’m all for unifying our efforts on this endeavor. In fact, I think that would really be best for the community as a whole. I think the end-user experience, as well as the plugin developer experience, will be optimized if plugins conform to a single standard based on a well-refined consensus.

I agree that putting this unified repository under the getpelican organization has significant benefits, including allowing any Pelican Dev Team member to contribute to it without any additional configuration management. Otherwise we’d have to manually invite members individually as repo collaborators. Using the GitHub organization features to manage a unified repository would help manage permissions much more efficiently.

If you don’t mind, I think the best way to proceed would be to add individual commits to the existing cookiecutter-pelican-plugin repository in an incremental, iterative fashion. I think the CookieCutter-based format will be easier for would-be plugin authors to utilize. In addition, there are a number of aspects there that align more closely to the future development for Pelican and its upcoming plugin ecosystem.

Regarding individual preferences, in no particular order… I don’t much care about licenses – I only put BSD as the default because it was the first one that came to mind. CookieCutter supports enumerations, so eventually I’ll add others to the list, and the author will be able to choose from that list upon initial instantiation.

Pipx isn’t really an alternative to Pipenv. I only mentioned Pipx in the other thread because it’s a good way to perform one-off runs of Python packages (such as CookieCutter) without having to install the package itself. That said, I presented a talk at EuroPython in Basel a few months ago and gave a full run-down on managing Python dependencies, in which I voiced a strong preference for Poetry over Pipenv. After my talk, several folks came up to me and said I was diplomatic and way too kind to Pipenv (I was). My assessment, and clearly that of these folks as well, is that Pipenv tries to do too much and accomplishes too little.

I would indeed prefer to use AutoPub for package releases. My expectation is that every plugin under the new pelican-plugins organization will be auto-published via AutoPub to PyPI upon pull request merge. It’s the best way to ensure new features and bug fixes are available to end users immediately.

I’d love to expand on this further, such expressing how much nicer GitHub’s new “Actions/Workflows” CI system is compared to Travis, but this has already become much longer than intended. Over time I’m sure we can learn a lot from each other by comparing notes like these in more detail.

Let me know what you think. I am excited at the prospect of collaborating with you on this shared endeavor!

[dreamalligator]

@justinmayer - I enjoyed that pipenv article. I agree that there are many hangups. My main one with pipenv is that, after using pipenv to start managing your dependencies, we all want to in the end have PyPI/pip integration, and sometimes that transition is hard to see to get to that final goal.

And I dont mind at all. I too think that combining efforts would really be best for the community as a whole. I'll come up with something simple to add to cookiecutter-pelican-plugin and see where we can go from there 👍

[justinmayer]

Fantastic. Looking forward to collaborating! 😁