Closed bsipocz closed 5 years ago
Having thought about this a bit more, I'd like to make sure we include https://github.com/astropy/package-template/pull/375 once it's finished before dropping python 2.
Actually the changes in #375 will require astropy-helpers 3.x, so let's not worry about that.
I'm on board with dropping Python 2 support now, but on the condition that we make a cookiecutter-2.x
branch and then include a note in the docs on how to run cookiecutter if you really want to generate a package that works with Python 2. Then we can always fix critical bugs in that branch if needed (but only critical bugs). I think for now we might also want to have the cookiecutter-2.x
branch be rendered to master
rather than do it from the cookiecutter
branch (remember that the master branch is only there for backward compatibility anyway)
I very much like the idea of making the bugfix branch for possible critical stuff.
However 👎 on making master rendered from that branch. The whole idea of dropping python2 would be to a bit more forcefully nagging packages along the path of dropping it. (As well as I would like using the rendered branch for tagging and then batchpr-ing to packages...). We can have a rendered-py2
branch if necessary, too, just please not the master
.
@bsipocz - ok I think I agree with you, but we have to document this well in the package-template docs.
As well as I would like using the rendered branch for tagging and then batchpr-ing to packages...
Would probably be better to render for each package, even if you just set "packagename" it would make the diff smaller.
Would probably be better to render for each package, even if you just set "packagename" it would make the diff smaller.
No, I'm not willing to go down in that rabbit whole, that'll the the job of the individual maintainers. I have the firm opinion to only issue batchPRs to packages for the files that are unambiguous, e.g. no package should modify the content (e.g. _astropy_init.py and alike) and only for tagged package template versions.
Since we don't have a rendered
branch, I think let's create a master-py2
branch, then in the docs mention that master
is now Python 3-only and that to remain Python 2-compatible, packages should switch to pulling from master-py2
. Once that's documented, I think this will be good to go.
cookiecutter-2.x
branch has been created as a copy of cookiecutter
as of today as well as a master-py2
.
I've added some docs, so this now is ready for final review and merging.
@pllim - I would leave any setup.py
related cleanup to #375 or being done separately after that PR if that's all right.
@bsipocz - can you rebase?
rebase done
all green and approved, so I go ahead and merge it.
To address #264