Roadmap

[cjolowicz]

This Cookiecutter template is currently in alpha, and expected to change significantly in terms of features and maturity. This umbrella issue provides a high-level overview of things that need to happen before we can leave alpha stage. For now, this is rather sketchy and incomplete, but hopefully better than nothing.

Here are some high-level features and fixes that are on the roadmap:

• Excellent native Windows support including step-by-step documentation

  • 1077

• Updating generated projects with changes from the template

  • 254

• Move Nox-Poetry integration into a package on PyPI

  • 567

  • 570

  • https://github.com/cjolowicz/cookiecutter-hypermodern-python-instance/pull/679
• Revisit the PyPI release workflow
  • Commitless releases?
  • Dynamic versioning?

  • 562

  • 440

For a detailed schedule of issues and PRs, see the milestones.

[paw-lu]

Updating generated projects with changes from the template

Just curious, have you evaluated libraries like cruft/cruft and copier-org/copier? Do they fall short in delivering this feature?

[jooh]

Excellent native Windows support including step-by-step documentation

What contributions are needed here? Could't see any issues in the milestones. We are trying out hypermodern in a fairly locked-down Windows 10 setup (no WSL) and so far everything just works! I notice the docs recommend going straight for WSL/ubuntu but that hasn't been necessary here so far. Happy to contribute docs or whatever workarounds prove necessary.

[cjolowicz]

@jooh thank you for the feedback! I was hoping that the only thing that needs updating would be the docs, specifically the section about local development with multiple versions of Python. To my knowledge, all that's needed on Windows for this to work is installing the official binaries from python.org, as Nox will find them via the Windows Python Launcher (py).

[cjolowicz]

Updating generated projects with changes from the template

Just curious, have you evaluated libraries like cruft/cruft and copier-org/copier? Do they fall short in delivering this feature?

@paw-lu Sorry for letting a year pass by without responding to this. I think both are excellent tools, and worth using. I have also been working on my own tool, which is not quite ready for a public announcement. I wanted to have something that is compatible with Cookiecutter, but not built on top of it, and that has a smooth workflow for importing individual changesets from templates into projects ("cherry-picking"). I'm being sketchy here, it's kinda early to talk about this :wink:

[paw-lu]

Sorry for letting a year pass by without responding to this.

Absoultley nothing to be sorry for! I think it's understood that we all have a backlog of messages.

I have also been working on my own tool, which is not quite ready for a public announcement.

Pretty sure I know what repo this is referring too, and I'm excited to try it out whenever you are ready to share!

[cjolowicz]

Hi @jooh #1087 updates the User Guide to cover native Windows development. Let me know if there's anything missing or inaccurate.

Edit: Read the Docs build for the PR is here.

[joelb123]

I have found this template has been extremely useful over the last few years, especially the community that has been built around it and the updates. However, poetry is not aging well for my use:

• The glaring problems with poetry's build system choices have become pretty obvious to those of us using it for computational science. This one bugs me every day, as I find myself having to manually change ^X.X.X to >=X.X.X every time I add a dependency. Frequently the only way to get a dependency updated is by deleting and re-adding it, or by tracking down the offender. I'm pretty annoyed at having to pin my python version as <3.12 just because pandas typedefs aren't ready to support 3.12 quite yet or have my builds break; I have better things to do with my time than update max versions.
• Poetry has decided to go its own way instead of implementing standards, most notably by inventing its own version specifications. I believe the PEP621 compliance is supposed to come in poetry v2, but why start a new project with a non-compliant pyproject.toml?
• There has been progress in better, faster, more standards-compliant build backends, notably hatch](https://hatch.pypa.io/latest/) and flit, but also good ol' setuptools.
• pdm, which occupies the same use space as poetry, has been developed. pdm is backend-agnostic., much faster to update, and more standards-compliant.

Ideally, the choice of pdm or poetry and pdm backends would be a cookiecutter-time choice, along the lines of plugins that I suggested. However, the deficiencies of cruft becomes more apparent to me with each update. Effort to update multiple projects based on the same cookiecutter template updated looks increasingly multiplicative than additive. Copier looks increasingly attractive in this regard, though I don't have any experience with it.

So, does the roadmap for this project look aggressively modern, or keeping what is working?

[cauliyang]

Additionally, we could consider replacing flake8 with the more modern and speedy linter, Ruff, which has recently gained popularity.