Skip to content

Conversation

@mtauraso
Copy link
Contributor

@mtauraso mtauraso commented Sep 30, 2024

Adding "better" python version propagation, and removing hardcoded python versions.

  • There are now three defined python versions you can use in templates, they are derived from python_versions and available through jinja macros.
  • py.pref(), py.max(), and py.min() are the macros, using the preferred import {%- import 'python-versions.jinja' as py -%}. Notably this is the only type of import that copier will accept in files who's pathnames contain templates. which eliminates several more syntactically ergonomic methods of achieving this same interface.
  • py.pref(python_versions), the preferred version, is the "middle-est" in the python_versions list, see python-versions.jinja for the math. For the default case where python_versions = [3.9,3.10,3,11], 3.10 is the preferred python version.
  • Hardcoded mentions of python 3.9 and python 3.10 have been set to py.min(python_versions) or py.pref(python_versions) respectively so that this change does not affect projects using the default configuration, and any python upgrade compatibility issues can be deferred until either the project template or an individual project changes python version support.
  • References to python_versions[0] have been replaced with py.min(python_versions) for consistency.

Change Description

Checklist

  • [ X ] This PR is meant for the lincc-frameworks/python-project-template repo and not a downstream one instead.
  • [ X ] This change is linked to an open issue
  • [ X ] This change includes integration testing, or is small enough to be covered by existing tests

…thon versions.

- There are now three defined python versions you can use in templates,
  they are derived from python_versions and available through jinja macros.
- py.pref(), py.max(), and py.min() are the macros, using the preferred import
  {%- import 'python-versions.jinja' as py -%}. Notably this is the only type
  of import that copier will accept in files who's pathnames contain templates.
  which eliminates several more syntactically ergonomic methods of achieving this
  same interface.
- py.pref(python_versions), the preferred version, is the "middle-est"
  in the python_versions list, see python-versions.jinja for the math. For
  the default case where python_versions = [3.9,3.10,3,11], 3.10 is the preferred
  python version.
- Hardcoded mentions of python 3.9 and python 3.10 have been
  set to py.min(python_versions) or py.pref(python_versions) respectively so that
  this change does not affect projects using the default configuration, and
  any python upgrade compatibility issues can be deferred until either the project
  template or an individual project changes python version support.
- References to python_versions[0] have been replaced with py.min(python_versions)
  for consistency.
@mtauraso mtauraso linked an issue Sep 30, 2024 that may be closed by this pull request
@mtauraso mtauraso self-assigned this Sep 30, 2024
@mtauraso mtauraso changed the title Adding "better" python version propagation, and removing hardcoded py… Adding "better" python version propagation, and removing hardcoded python versions. Sep 30, 2024
Copy link
Contributor

@camposandro camposandro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know this was possible! Looks great.

@mtauraso mtauraso merged commit 8aa5e4a into main Oct 1, 2024
@mtauraso mtauraso deleted the issue/462/python-version branch October 1, 2024 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Minimum python version should propagate better

4 participants