pelican-cite
pelican-cite copied to clipboard
VorpalBlade
Create an installable version
Hello,
Even though Pelican has it's own system to "install" plugins by cloning the entire repository, I still prefer to use a package manager.
They even made a cookiecutter to create a new plugin. The only downside would be that users will have to add pelican.plugins.pelican_cite instead of pelican_cite to the PLUGINS list.
Would you mind if I change your project with the cookiecutter and send a pull request?
Hi, I just took over as the maintainer, and I plan to put this package on PyPI in the near future. I'm not familiar with cookiecutter, What is the advantage of cookiecutter for an existing project, as opposed to just adding a setup.py and uploading it to PyPI instead? Especially since in that case the package name doesn't need to change.
Hi @VorpalBlade,
Cookiecutter is just a way to scaffold a project layout. The cookiecutter uses Poetry instead of setyp.py. in it's turn, Poetry uses pyproject.toml.
On another note. I forked the project a while ago and made some significant changes to make it more flexible. https://github.com/johanvergeer/pelican-cite I also extracted the label to another project (https://github.com/johanvergeer/pybtex-author-year-label). This way other Pybtex projects can use it, and users of pelican-cite can use other label types.
Can you take a look and tell me what you think?
I'm currently sick in influensa. I will get back to you once I'm better.
@johanvergeer Hm, it seems you already created a PyPI package for pelican-cite, which I tried to upload today. This is a bit awkward. Hopefully we can come to a good solution to this.
While I looked at the cookiecutter thing, I could not really see any advantage of it compared to a simple setup.py. However, I would be very interested in pull requests for other features you have developed.
@VorpalBlade What would be the benefit of using a setup.py instead of pyproject.toml. Especially since pyproject.toml is the new standard.
I've actually already added a lot of tests and made some major changes, so which ones would you be interested in?
After reading up on pyproject.toml seems to just be a way to specify what build tool you want to use, e.g. setuptools, or something else. I have nothing against that. But I have no interest in then switching to one of those alternative build tools. Especially since for a simple project like this, setuptools is more than enough in terms of functionality.
As for what parts to pull in: unit and integration tests are of course welcome. I also see you seem to have extracted author_year.py. I'm definitely in favour of this sort of modularisation.
However, you seem to have broken traditional pelican-style install (e.g. via https://github.com/getpelican/pelican-plugins). This can be easily fixed by adding a shim init.py in the root of the repository.