Otherwise, 3.10 is interpreted as 3.1.

https://github.com/actions/setup-python#usage

https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository#changing-the-used-by-package

Separate Cookiecutter input for the project's distribution name.

https://packaging.python.org/en/latest/tutorials/packaging-projects/#configuring-metadata

Related to #33 and #18.
Forgot to add src/ to the beginning of the version location.

From CONTRIBUTING.md to its own file.

Related to #51.

https://github.com/MicaelJarniac/timematic/runs/4422865676?check_suite_focus=true#step:5:13

Possibly related to #18.

Some workflows are set to 3.8 only, some are 3.7 and 3.8.

https://github.com/readthedocs/recommonmark

Related to #25
Related to #29

https://docs.readthedocs.io/en/stable/guides/private-python-packages.html#from-a-git-repository

Python 3.6 reached EOL today.
https://endoflife.date/python
Related to #46.

pydocstyle is configured to only run on files inside the src/ dir, but flake8-docstrings doesn't seem to respect that.

Things like documentation, source code...

• Changelog
• Documentation
• Code (sphinx) / Source (pytest, flake8-black) / Repository (mypy) / Source Code (nox)
• Issue Tracker (sphinx) / Issues (coveragepy) / Tracker (pytest, flake8-black) / Bug Tracker (nox)

https://github.com/pradyunsg/furo

build==0.7.0 is on the requirements-dev.txt but I don't remember if it's actually necessary.

https://www.contributor-covenant.org/version/2/1/code_of_conduct/

https://github.com/MicaelJarniac/cookiecutter-python-project/blob/4b8b920e79bd062fc4bb1381979c48878648eb28/cookiecutter.json#L10

It's currently using ["yes", "no"].

Related to #40.
Related to cookiecutter/cookiecutter#126.

virtualenv seems to have more features than venv:
https://virtualenv.pypa.io/en/latest/

For installing multiple Python versions, pyenv seems nice:
https://github.com/pyenv/pyenv

https://tox.wiki/en/latest/

Mypy quite often needs a complete set of requirements installed in order to function properly.

pre-commit creates a fresh environment for each hook and basically doesn't install anything other than the hook itself.

We can provide additional dependencies for pre-commit to install along with the hook, but that'd mean duplicating the requirements and having to maintain them both up-to-date.

A pre-commit hook can be run from the external environment, instead of its isolated one, but that'd then make it dependant on a properly configured environment, which won't always be the case, and that'd limit where pre-commit can be run from.

Another option would be to have the hook install the full set of requirements, but that'd add a considerable slowdown.

Since running pytest already requires a fully working environment, that could be a nice place to have Mypy run.

Perhaps a subset of Mypy features can still be called from pre-commit.

https://jaredkhan.com/blog/mypy-pre-commit
pre-commit/pre-commit#880 (comment)
https://github.com/dbader/pytest-mypy

python-semantic-release/python-semantic-release#355

from ._project import Something

__all__ = ["Something"]

Related to #23

It might not be necessary to include the AllContributors configuration.

Maybe add an empty dependencies list, and/or document how to populate the list.

Add some very simple code to work as an example on how to write docstrings, how to import the code for tests, and so on.

I'm still thinking if this would be the best choice.
This could help with making tool configurations simpler.

https://endoflife.date/python

https://code.visualstudio.com/docs/editor/extension-marketplace

Set up Black, Flake8, and Mypy to be used.

# Get more from http://pypi.python.org/pypi?%3Aaction=list_classifiers

• Programming Language :: Python :: 3.7
• Programming Language :: Python :: 3.8
• Programming Language :: Python :: 3.9
• Programming Language :: Python :: 3.10
• Development Status :: ?
• Intended Audience :: ?
• Topic :: ?
• Natural Language :: English

Python Semantic Release seems to not be triggered on the initial commit, possibly because of it not having an adequate name, so it'd be great to have the initial commit be 0.0.0 and then add a commit like feat: initial release to do the first version bump properly.

• MicaelJarniac/crustypy-instance#1

I'm not sure if Poetry would be a good fit for this template, but it'd be interesting to take a better look into it.
https://python-poetry.org/docs/basic-usage/

Ensure the following work with Poetry:

• Nox
• Python Semantic Release
• Documentation building on ReadTheDocs

poetry config virtualenvs.in-project

Wishlist

• cjolowicz/nox-poetry#887
• cjolowicz/nox-poetry#1040
• cjolowicz/nox-poetry#1080
• python-poetry/poetry#3332
• python-poetry/roadmap#3
• python-poetry/poetry-core#567

It'd be cool to have the version displayed on the bottom of the generated project's README as well, alongside the credits.

It's currently project/project.py, but it might be better if it's project/_project.py, so it's considered "private", and its "public" parts can be "exported" on project/__init__.py.

https://docs.readthedocs.io/en/stable/tutorial/
https://docs.readthedocs.io/en/stable/guides/reproducible-builds.html
https://docs.readthedocs.io/en/stable/config-file/v2.html#supported-settings

• Create config files
• Document how to set up Read the Docs
  • Enable individual versions

It's currently complaining about tests/ and docs/, as well as setup.py.

Related to #18

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms

Like in https://pradyunsg.me/furo/quickstart/

https://pradyunsg.me/furo/recommendations/

Some files, especially configurations, are starting to pile up on the project root. It'd be great to find a better solution, maybe having them inside a different folder, maybe finding ways to merge some of them...

• CONTRIBUTING.md can be inside docs/ - GitHub documentation
• CODE_OF_CONDUCT.md can be inside docs/ - GitHub documentation
• README.md can be inside docs/ - GitHub documentation (not too sure whether this is a good idea, though)
  • Requires updating .all-contributorsrc
• CHANGELOG.md can be inside docs/ - Python Semantic Release documentation
• .all-contributorsrc may be allowed in .github/ soon - all-contributors/cli#328

On setup.cfg, the required Python version is >= 3.6, but the testing workflow tests only 3.7 and 3.8.

Related to #7.

Related to #40.
If not using Discord, default its related fields to something like ignored or inactive, to make it less confusing.
As far as I know, we can't simply tell Cookiecutter to not show those fields, so this might be the best approach for now.

https://github.com/pypa/pipfile

Related to #12.

On testing workflows, the project has to be installed with pip install . before tests can be run.

Something similar to https://github.com/audreyfeldroy/cookiecutter-pypackage/tree/master/%7B%7Bcookiecutter.project_slug%7D%7D#credits

Retrocookie

retrocookie ../crustypy-instance/ COMMIT_HASH --exclude-variable use_discord_community --exclude-variable year

Issues

• https://github.com/MicaelJarniac/cookiecutter-python-project/labels/postponed open & closed
• https://github.com/MicaelJarniac/cookiecutter-python-project/labels/info open & closed

Related to #41.
I'm still not too sure about this one, but I think it does make sense for some tools to only run inside src/.

Maybe just ignoring venv/ and .venv/ might do the trick for most tools.