If you generate a package and say yes to all the defaults, you get a package called wagtail-localize authored by Karl Hobley, etc. Lets replace the defaults with something more 'defaultey'.
https://github.com/wagtail/cookiecutter-wagtail-package/blob/main/cookiecutter.json

In cookiecutter.json we define a version param, which we then use in

We should either drop version from cookiecutter.json and hard-code 0.1.0 in CHANGELOG.md or use the value of version in __init__.py

• https://docs.pypi.org/trusted-publishers/
• https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-pypi

Python 3.7 is EOL in less than 4 months.
Wagtail < 4.1 (the latest LTS) is no longer supported

• Now that Black is being used in Wagtail core, and a 'must' for new Wagtail projects we should adopt in this cookiecutter also

Based on discussion on Slack – over Django’s built-in test runner, pytest is faster, has more plugins (code coverage, memory benchmarking, etc).

On creating a project named wagtail-editable-help, and omitting the "wagtail-" prefix from the prompts as instructed:

$ cookiecutter [email protected]:wagtail/cookiecutter-wagtail-package.git
You've downloaded /Users/matthew/.cookiecutters/cookiecutter-wagtail-package before. Is it okay to delete and re-download it? [yes]:
full_name [Karl Hobley]: Matt Westcott
email [[email protected]]: [email protected]
github_username [kaedroho]: gasman
project_name [Localize]: Editable Help
project_name_snake [editable_help]:
project_name_kebab [editable-help]:
project_name_camel [EditableHelp]:

the name in setup.py is set to wagtail-editable-help, implying that that's what the PyPI package is going to be called. However, the two references to the PyPI package name in the readme have it without the wagtail-:

[![PyPI version](https://badge.fury.io/py/editable-help.svg)](https://badge.fury.io/py/editable-help)

and

- `pip install editable-help`

The wagtail- prefix is also (consistently) missing from the Github repo name. I'm not sure if this is intentional or not, but it goes against what all the existing packages under the Wagtail organisation do. (Probably worth noting that if we do add the prefix here, the only remaining un-prefixed occurrence of the name in the codebase will be the URL path registered in wagtail_hooks.)

It is a useful package, but unlike dj-database-url I don't think there is anything in the template that actually requires it. I think we should just drop it completely as it is an unnecessary opinion. As a package author, you may not need it at all. You might need this functionality but prefer time-machine.

I don't thing there's any need to bundle them in the built package. Smaller package sizes == happier devs and planet.

Dev reference: https://hynek.me/articles/testing-packaging/ | https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure

Project structure:

src/
╰─ project_name/
   ╰─ ...
tests/
╰─ ...

<configuration files etc>

https://github.com/wagtail/wagtail-localize/pull/480/files#r740987231

Add django 5.0 to matrix for compatible combinations of python/wagtail

re: https://docs.djangoproject.com/en/5.0/releases/5.0/#third-party-library-support-for-older-version-of-django should we also start dropping django 3.2 out for new packages, or should we keep it in while in-range wagtail versions still support it?

Refs #59 (comment)

Not quite ready yet, but wagtail 5.2 will be out in the next few weeks

One of the changes proposed in #51 was to replace isort and flake8 with ruff. This needed some more work though as ruff is not config-compatible with isort and flake8 so we would need to migrate the config https://github.com/wagtail/cookiecutter-wagtail-package/blob/main/%7B%7B%20cookiecutter.__project_name_kebab%20%7D%7D/setup.cfg to a ruff.toml (shouldn't be a huge job)

On the plus side, this would align us with wagtail core, which is now using ruff. Also all the cool kids are using ruff now 😎

That said, ruff is most beneficial for huge codebases. Plugins tend to be small. Isort/flake8 are still great tools so this is not the highest priority issue in the backlog right now.

There are a lot of places where we need to remember to use

• wagtail-{{ cookiecutter.project_name_kebab }}
• wagtail_{{ cookiecutter.project_name_snake }}

We should make convenience variables for {{ cookiecutter.project_name_kebab_prefixed }} and {{ cookiecutter.project_name_snake_prefixed }} to make it a bit easier to "fall into the pit of success". These should be cookiecutter private variables so the user is not prompted. Also probably some of our existing variables can probably be converted to private variables so we are only asking the user questions they need to answer.

Probably Makefile.
Refs #47 (comment)

1. for this repos tests
2. for the generated package

Rationale: keeps the management of things in one place. While GHA can be considered a single point of failure, it also removes complexity which we want here. Should a package maintainer go with Circle CI, or something else, that is their prerogative

This is a follow-up to #19 – "BSD license" is an umbrella term for 4 different OSI-approved licenses, most commonly only the 2-clause and 3-clause variants:

• 0-clause BSD License (0BSD)
• 1-clause BSD License (BSD-1-Clause)
• 2-clause BSD License (BSD-2-Clause)
• 3-clause BSD License (BSD-3-Clause)

I believe what this project has set up in its template is the "3-clause BSD License". I think it would be better if our cookiecutter.json used SPDX license identifiers, so BSD-3-Clause.

Node 16 is now end of life and will not receive any new updates, we should change the default to the current active LTS (version 20).

https://endoflife.date/nodejs

There is a need to keep this package up-to-date as new versions of python/django/wagtail are released. This does require some manual intervention to update the trove classifiers, tox matrix, etc. However it would be nice to have a bot submit a PR as a prompt for me to do this when a new release is available.
Unfortunately, for this repo it is not as simple as just pointing dependabot at it and telling it to bump the ranges because our pyproject.toml is (will be) a valid jinja template, but it is not valid toml.
Need to have a think about how to approach this.

Nice package @kaedroho !
A few nice to haves:

• add Framework :: Wagtail :: 2 to classifiers in setup.py
• make author/email configurable
• make register_admin_urls a placeholder (currently it has a very specific package implementation)

I haven't yet added a question into the cookiecutter config that excludes this. So if you don't want it, delete it.

As of #28 packages generated from this template come with a pre-commit config, but it feels like our approach to this is all over the map. I probably should have identified this more clearly in the review of #28 . We got trigger happy on the merge :(

In the generated package:

• Python-based tooling is completely delegated to pre-commit. Black, flake8, isort etc are specified in .pre-commit-config.yaml but they're not specified as dev dependencies in pyproject.toml.
• We specify a version of prettier in .pre-commit-config.yaml Independently we specify a different version of prettier in package.json.
• Also in package.json we specify versions of eslint and stylelint + commands for running them, but they aren't run as pre-commit hooks.

In the template repo:

• We pip install flake8 (which doesn't necessarily check the same version pinned in .pre-commit-config.yaml ) in the CI build and check the generated package against it.
• We check the generated package against the versions of stylelint/eslint/prettier specified in package.json
• We don't run black/isort/any of the other checks

As it stands, this is not very consistent. We need to fundamentally pick an approach and apply it consistently everywhere. Either dev tools are managed entirely by pre-commit and not installed as dev dependencies or they're both (regardless of ecosystem) and the tools/versions we run against in the template repo CI should be the same what is in the generated package.

https://github.com/ymyzk/tox-gh-actions/

https://github.com/torchbox/wagtail-storages looks like a pretty sensible example project to crib the setup from

CI has been failing on main since #20

e.g: https://app.circleci.com/jobs/github/wagtail/cookiecutter-wagtail-package/249

I tried reproducing this locally and I don't get the same failure, but I do get different errors 🙃 . I think this may be dodgy cacheing related to using persist_to_workspace in Circle CI. I'm going to ignore this and deal with it when I pick up #34