Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for python2.7 #1386

Merged
merged 7 commits into from May 26, 2020
Merged

Conversation

ssbarnea
Copy link
Member

@ssbarnea ssbarnea commented Apr 21, 2020

Python 2.7 is officially dead and we are not going to make any new release that supports it.

This removes py27 code but a follow-up will address other changes like removing use of six.

Major version is bumped to 1.8.0 to mark this breaking change.

@ssbarnea ssbarnea added the breaking-change Marks an important and likely breaking change. Require update for major version label Apr 21, 2020
@ssbarnea ssbarnea added this to the 1.8.0 milestone Apr 21, 2020
@ssbarnea ssbarnea marked this pull request as ready for review Apr 21, 2020
@ssbarnea ssbarnea self-assigned this Apr 21, 2020
@hackebrot
Copy link
Member

hackebrot commented Apr 21, 2020

Hi @ssbarnea! 👋

Dropping Python 2 compatibility is a breaking change and requires a major version bump to version 2.0.0 as well as the PyPI classifier Programming Language :: Python :: 3 :: Only.

@ssbarnea
Copy link
Member Author

ssbarnea commented Apr 21, 2020

Hi @ssbarnea! 👋

Dropping Python 2 compatibility is a breaking change and requires a major version bump to version 2.0.0 as well as the PyPI classifier Programming Language :: Python :: 3 :: Only.

I do not mind using 2.0.0, mostly I got used to other projects where top version is used only on serious architectural changes, second is major, 3rd is minor, and 4th is optional and used only for hotfixes. Example ansible project(s).

Anyway, I will update it to 2.0.0. The only worry I have is that as we want to move to a faster release cycle with breaking changes we risk starting to bump the first number quite often. Still, browsers demonstrated that nobody got hurt by this practice.

@ssbarnea
Copy link
Member Author

ssbarnea commented Apr 21, 2020

BTW, I am really inclined to want to drop py35 too because is nearly end-of life and because having py36 as minimal would enable a serious list of improvements like f-strings or type-checking. Still, that decision is outside the scope of this PR. I want to keep any chance atomic, so is easy to review.

@ssbarnea
Copy link
Member Author

ssbarnea commented Apr 21, 2020

As it appears coverage does really helped this time.

Copy link
Member

@insspb insspb left a comment

In setup.py Jinja2 limits should be removed, current limit is only to keep Python2 compatibility.
Other dependencies limits should be rechecked.

@@ -70,7 +69,7 @@ At the command line:

.. code-block:: bash

$ pip install --user cookiecutter
$ pip3 install --user cookiecutter
Copy link
Member

@insspb insspb Apr 21, 2020

Choose a reason for hiding this comment

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

Suggested change
$ pip3 install --user cookiecutter
$ pip install --user cookiecutter

It always pip. We do not care about user simlinks, we care only about normal setup.
On modern systems python2 not exist.
And you will get:

insspb@insspb-notebook:~$ pip -V
pip 20.0.2 from /usr/local/lib/python3.8/dist-packages/pip (python 3.8)

Copy link
Member Author

@ssbarnea ssbarnea Apr 21, 2020

Choose a reason for hiding this comment

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

I am 100% sure that on modern systems like CentOS 8, pip gets installed as pip3 and non pip. Some applies to virtualenv.

If you want, a more generic command would be python3 -m pip install ..., which is probably the most portable example.

pip + virtualenv are special tools which need the version prefix to avoid conflicts with their py3 versions.

Copy link
Contributor

@luzfcb luzfcb Apr 21, 2020

Choose a reason for hiding this comment

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

I can confirm the same behavior on Debian Buster on docker. When installing python3 and python3-pip, there is no python or pip executables, only python3 and pip3.

Anyway, +1 to python3 -m pip install

Copy link
Member

@insspb insspb Apr 22, 2020

Choose a reason for hiding this comment

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

+1 to python3 -m pip install

@@ -133,6 +132,6 @@ Or with pip:

.. code-block:: bash

$ pip install --upgrade cookiecutter
$ pip3 install --upgrade cookiecutter
Copy link
Member

@insspb insspb Apr 21, 2020

Choose a reason for hiding this comment

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

Suggested change
$ pip3 install --upgrade cookiecutter
$ pip install --upgrade cookiecutter

Same as above

@insspb
Copy link
Member

insspb commented Apr 21, 2020

@ssbarnea Please remember that PR title will be in changelog. So it should start with Changed:/Updated: etc keywords.

@pydanny
Copy link
Member

pydanny commented Apr 21, 2020

Just want to say that this is a wonderful development. Very exciting to watch unfold. Go go go!

@ssbarnea
Copy link
Member Author

ssbarnea commented Apr 22, 2020

@ssbarnea Please remember that PR title will be in changelog. So it should start with Changed:/Updated: etc keywords.

Not sure where this requirement comes from. The good part about using Release Drafter is that we can change the PR title and labels even after the merge and the notes will be updated, as long we do not tag a new release. This gives us time to tune it.

AFAIK, PRs should be concise, easy to read, follow 50/72 rule as commits and use at least one label that is recognized by the drafter. Sadly there is no bot to check that, yet.

Re jinja2<3.0.0 or markupsafe<2.0.0 are good to stay, there is no such releases. It is not a bad idea to limit major versions as they are high-likely to break backward compatibility. Only real problem is with packages that bump major version often, but apparently we do not have any problems of this kind with our dependencies.

@pydanny Thanks for the message, I am happy to get some confirmation on our actions. Sometimes we worry that we could end-up making unpopular changes.

@ssbarnea ssbarnea changed the title Drop support for python2.7 Remove support for python2.7 Apr 22, 2020
Python 2.7 is officially dead and we are not going to make any new
release that supports it.

This removes py27 code but a follow-up will address other changes
like dropping the need to use six library.
@insspb insspb added this to In progress in 2.0.0 Release via automation Apr 24, 2020
@insspb
Copy link
Member

insspb commented Apr 24, 2020

@ssbarnea LGTM, but what about 3.5?

insspb
insspb approved these changes Apr 24, 2020
2.0.0 Release automation moved this from In progress to Approved Apr 24, 2020
insspb
insspb approved these changes May 26, 2020
@insspb insspb merged commit d9bd728 into cookiecutter:master May 26, 2020
1 of 2 checks passed
2.0.0 Release automation moved this from Approved to Merged May 26, 2020
@simobasso simobasso mentioned this pull request May 15, 2021
@pjbull pjbull mentioned this pull request Jul 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Marks an important and likely breaking change. Require update for major version
Projects
2.0.0 Release
  
Merged
Development

Successfully merging this pull request may close these issues.

None yet

5 participants