ionelmc / cookiecutter-pylibrary

Enhanced cookiecutter template for Python libraries.
BSD 2-Clause "Simplified" License
1.25k stars 207 forks source link

Shortcut option to disable python 2 versions #214

Closed Querela closed 3 years ago

Querela commented 3 years ago

As support for python 2 runs out, maybe it would be nice to have an option to disable all python 2 versions (python2.7, pypy) in the tox environments and the setup.py?

Alternatively, but it requires more work for postprocessing, an option to specify start and end python versions, e.g. 3.6 to 3.9.

It's more of an comfort feature as it's just deletion and modifications in various places. But it would make it easier and less error prone. In my opinion, adding support for python2.7 for new packages should not be necessary anymore, and requirements for this should slowly vanish as time goes on. But completely removing it from the template might still be to soon. (Some edge cases might still exist.)

ionelmc commented 3 years ago

Yes there could be an option for removing the py2 stuff. It could even be enabled by default (it's probably just me and few other people still maintaining py2 stuff). Are you interested in contributing?

Querela commented 3 years ago

Well, that seems easy enough. So, yes, why not? :-) Not sure when exactly I will get to it but before the year ends. Any thoughts on the name of the feature? For cookie cutter?

ionelmc commented 3 years ago

Well there are several options like "legacy_python" "disable_python2" "python2" "python3_only" or even "no_python2" - if you contribute you have freedom to choose whatever you like but I'd stay clear of double negations - it grinds my gears to see things like "no_something='no'".

Querela commented 3 years ago

Ok. Makes sense. And yes, I wanted to stay away from double negations. I was thinking about python2 or with _enable/_support. Or python3_only but when python4 comes out, this will be confusing. And without documentation, some variants are not really expressive when using cookiecutter ... I think legacy_python might be good, as it describes all python versions that might not be supported anymore. Alternatively, (future-proofing) python2 [yes|no] which also allows for python3 [yes|no] and python4 [yes|no]

Querela commented 3 years ago

Hmm. I also updated the c extension code to remove the # macros for version checks.

In the appveyor config template I found no docs jobs? (just after checks)

Querela commented 3 years ago

Should I update the Changelog file? There is no section for WIP/next version.


And I'm slightly confused about the setup.cfg for the tests:

legacy_python =
    : yes
    nolegacy: no

That's probably ok. But then I'm not how to reduce the number tests? (they doubled more or less) The matrix package did not really explain how to do this. And experimenting seems to work somewhat but is not really clear for me. The following seem to help reduce the tests but &command_line_interface[plain] seems to recursively include the options which is confusing...

command_line_interface =
    click &legacy_python[yes]
    : plain
    argparse &legacy_python[yes]
    nocli &legacy_python[yes]

Locally, I tested it with python3.8 (instead of python3.6), it seemed to work. (no python2.7 for testing ...)

_______________________________________________________ summary ________________________________________________________
  py38-cext: commands succeeded
  py38-cext-nolegacy: commands succeeded
  py38-cffi: commands succeeded
  py38-cffi-nolegacy: commands succeeded
  py38-cython: commands succeeded
  py38-cython-nolegacy: commands succeeded
  py38-matrix-cext: commands succeeded
  py38-matrix-cext-nolegacy: commands succeeded
  py38-matrix-separate-cext: commands succeeded
  py38-matrix-separate-cext-nolegacy: commands succeeded
  py38-nose-pure: commands succeeded
  py38-nose-pure-argparse: commands succeeded
  py38-nose-pure-click: commands succeeded
  py38-nose-pure-nocli: commands succeeded
  py38-pure: commands succeeded
  py38-pure-argparse: commands succeeded
  py38-pure-click: commands succeeded
  py38-pure-nocli: commands succeeded
  py38-pure-nolegacy: commands succeeded
  py38-pure-private: commands succeeded
  py38-pure-pylama: commands succeeded
  py38-separate-cext: commands succeeded
  py38-separate-cext-nolegacy: commands succeeded
  py38-separate-cext-scm-osx-publish: commands succeeded
  py38-separate-cffi: commands succeeded
  py38-separate-cffi-nolegacy: commands succeeded
  py38-separate-cffi-scm-osx-publish: commands succeeded
  py38-separate-cython: commands succeeded
  py38-separate-cython-nolegacy: commands succeeded
  py38-separate-cython-scm-osx-publish: commands succeeded
  py38-separate-nose-pure: commands succeeded
  py38-separate-pure: commands succeeded
  py38-separate-pure-nolegacy: commands succeeded
  congratulations :)

Is this an error:

travis_osx =
    : no yes &c_extension_test_pypi[no]
    osx: yes &c_extension_test_pypi[yes]

The no yes?


And in the travis.yml is a section that does not automatically regenerate:

      # This is clunky, but hopefully soon https://github.com/pypa/pip/issues/6264 will be fixed so it won't matter anymore.
      if [ -e pyproject.toml ]; then
        echo "We have a PEP517 pyproject.toml, and the Travis PyPy installation has an old setuptools, so we cannot allow system site packages as long as pip has the build isolation bug."
        tox
      else
        echo "As long as we're not using PEP517, it's safe to use system site packages."
        tox --sitepackages
      fi
Querela commented 3 years ago

Should I prepare for Python3.5 being deprecated next?

DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021.

Next month, it might be a 'legacy python', too... Should users then automatically stop creating new packages that target this version?

ionelmc commented 3 years ago

I believe we can simply remove 3.5. No one is going to have a problem upgrading from py3.x to py3.x+1, unlike with py2...

Querela commented 3 years ago

Ok.


The README.rst refers to older versions:

Tox for managing test environments for Python 2.7, 3.3, PyPy etc. Pytest or Nose for testing Python 2.7, 3.3, PyPy etc.

I'm currently not sure whether I should just keep it so, change it to 2.7, 3.x, PyPy, or something else?


Tests look ok so far, but I want to see them all finished, not just halfway because of newer commits.

ionelmc commented 3 years ago

Closed via d4bd03b.