astropy / package-template

Template for packages that use Astropy. Maintainer: @astrofrog
http://docs.astropy.org/projects/package-template/en/latest/
Other
60 stars 63 forks source link

Remove python2 from the template #385

Closed bsipocz closed 5 years ago

bsipocz commented 5 years ago

To address #264

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

astrofrog commented 5 years ago

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)

bsipocz commented 5 years ago

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.

astrofrog commented 5 years ago

@bsipocz - ok I think I agree with you, but we have to document this well in the package-template docs.

Cadair commented 5 years ago

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.

bsipocz commented 5 years ago

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.

astrofrog commented 5 years ago

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.

bsipocz commented 5 years ago

cookiecutter-2.x branch has been created as a copy of cookiecutter as of today as well as a master-py2.

bsipocz commented 5 years ago

I've added some docs, so this now is ready for final review and merging.

bsipocz commented 5 years ago

@pllim - I would leave any setup.py related cleanup to #375 or being done separately after that PR if that's all right.

astrofrog commented 5 years ago

@bsipocz - can you rebase?

bsipocz commented 5 years ago

rebase done

bsipocz commented 5 years ago

all green and approved, so I go ahead and merge it.