Closed Querela closed 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?
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?
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'".
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]
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)
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
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?
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...
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.
Closed via d4bd03b.
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.)