Shortcut option to disable python 2 versions about cookiecutter-pylibrary HOT 10 CLOSED

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?

from cookiecutter-pylibrary.

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?

from cookiecutter-pylibrary.

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'".

from cookiecutter-pylibrary.

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]

from cookiecutter-pylibrary.

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)

from cookiecutter-pylibrary.

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

from cookiecutter-pylibrary.

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?

from cookiecutter-pylibrary.

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...

from cookiecutter-pylibrary.

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.

from cookiecutter-pylibrary.

Closed via d4bd03b.

from cookiecutter-pylibrary.