Closed justinmayer closed 4 years ago
I'm not familiar with many of the changes and/or tools used in this PR, so I am not qualified to review. My only comment is that all of this seems overkill and sets a steeper barrier for contributing a plugin. If this is what the pelican community has decided on that's what it will be.
Thank you for taking the time to have a look, Jason. Could you perhaps elaborate as to what specifically you think is overkill? And which parts do you believe serve as a barrier to contributing?
This introduces:
All of these are unnecessary for packaging a python distribution and add overhead to understand what's going on when a setup.py file is plenty sufficient (especially for plugins which are typically small programs).
Thank you for elaborating. I spent a considerable amount of time making these changes, so obviously I think they have value. But I understand you find some of these modifications to be unnecessary. I'm still not clear, however, as to why they pose a barrier to contributing.
A few comments on the items you mentioned…
This pull request does not, in fact, add Tox. Flake8 does not yet support configuration directives within pyproject.toml
, so those settings must unfortunately live somewhere else. Since tox.ini
is one of the few supported configuration locations, that is where I (reluctantly) chose to store those settings for now. Once Flake8 can read from pyproject.toml
, the tox.ini
file can be removed.
I added Black and isort because, in my experience, they make it easier — not harder — for developers to contribute by taking the guesswork out of code formatting and import organization, respectively.
The pyproject.toml
file facilitates the consolidation of myriad disparate configuration files into a single file with a sane, consistent file format. Combining it with Poetry adds dependency resolution and increments version numbers automatically, but I understand those features aren't strictly necessary.
I was on the fence about removing the setup.py
file and would be okay with restoring it. Would that help alleviate some of your concern about these changes?
To be clear, I'm not blocking this PR. My original post indicated that I'm not going to review it. I'm a user and only very minor contributor in this community, so you or others can make a call as to whether this repository format and set of tools should be used for plugins.
I know what all of the tools are for, it just turns out that I'm personally not interested in using them, so its best for me to abstain from the review.
Thank you for reiterating your stance, Jason. I understand better now.
I restored the setup.py and version.py files and updated them appropriately.
I took the liberty of applying the new Pelican plugin template to the Render Math plugin, the results of which can be found in this pull request. I also gave the README a thorough overhaul.
Once this is merged, I will submit a PR that switches from Travis to GitHub Actions, utilizing their built-in CI for running tests as well as for automatically releasing new versions to PyPI. ✨