Better releases #593
Better releases #593
Conversation
docs/source/development_release.rst
Outdated
| Assign all merged PRs to milestones | ||
| ----------------------------------- | ||
|
|
||
| Go to GitHub and assign all PRs that have been merged to milestones. |
There was a problem hiding this comment.
We can provide a handy link here to PRs merged with no milestone:
https://github.com/jupyter/nbconvert/pulls?utf8=%E2%9C%93&q=is%3Amerged%20is%3Apr%20no%3Amilestone%20
docs/source/development_release.rst
Outdated
| Create the release | ||
| ------------------ | ||
|
|
||
| #. Update the changelog to account for all the PRs assigned to this milestone. |
There was a problem hiding this comment.
Should this explicitly mention where the changelog file is?
There was a problem hiding this comment.
Relative to the top level? or relative to the location of this file?
docs/source/development_release.rst
Outdated
| git push upstream | ||
| git push upstream --tags | ||
|
|
||
| #. Push tages on master forgetting to push ``--tags`` too. |
There was a problem hiding this comment.
This looks like a confused copy of the point immediately above?
There was a problem hiding this comment.
yes i think I was in the middle of splitting one thing in the original notebook, but then realised that I could just have the raw code as two lines.
| @@ -0,0 +1,80 @@ | |||
| .. _nbconvert_release: | |||
|
|
|||
| Making an ``nbconvert`` release | |||
There was a problem hiding this comment.
Have you checked a built copy of this? I can't remember if backticks in headings work.
nbconvert/_version_tools.py
Outdated
| @@ -0,0 +1,83 @@ | |||
| # import pep440 # cannot be imported as described below | |||
| import re | |||
There was a problem hiding this comment.
This file looks like it's copied from somewhere - can we have a comment at the top clearly saying where, including what version (or commit, if necessary)? We may also need to include a copyright notice and license text.
There was a problem hiding this comment.
It's @Carreau's pep440, github (to which you've committed, which is why I assumed this would be caught), we can add a copyright notice if you like. Basically I'd just use it directly but for the fact that it can't be built with setuptools. That seemed like it was a design choice and if not I was going to make a PR today.
There was a problem hiding this comment.
Also I should mention I thought that I had included that comment at the top and in the main text, I guess the only thing that's missing is a github link I will fix that.
There was a problem hiding this comment.
Yeah, put an explicit Github link and a commit ID, for good measure.
I don't personally mind about the copyright notice & license text, and @Carreau may well not mind either. In general, though, if we're including code from another project, we should include those things - it's a typical condition of the licenses which allow you to redistribute that code.
There was a problem hiding this comment.
You may also just copy past the is_cannonical from pep 440 itself that was added recently to make this kind of things easier.
I'll make my pep440 easier to vendor.
There was a problem hiding this comment.
Got it from pep440 itself Appendix B.
setup.py
Outdated
| 'serve': ['tornado>=4.0'], | ||
| 'execute': ['jupyter_client>=4.2'], | ||
| } | ||
| s = [] | ||
| [s.extend(values) for values in extra_requirements.values()] |
There was a problem hiding this comment.
I don't like using list comprehensions for side effects. I'd either do this with a regular for loop:
for reqs in extra_requirements.values():
s.extend(reqs)Or get clever with sum:
s = sum(extra_requirements.values(), [])There was a problem hiding this comment.
I did not know that sum could be applied to lists. I'm intrigued because that could allow: extra_requirements['all'] = sum(extra_requirements.values(), []). Which is perhaps a bit too clever but totally does the trick.
There was a problem hiding this comment.
Yep, I think that would be OK.
I believe that sum can accept anything which you can combine with the + operator. If you're not using it for numbers, though, you need to give the second argument for the starting value.
setup.py
Outdated
| extra_requirements['all'] = list(set(s)) | ||
|
|
||
| extras_require = setuptools_args['extras_require'] = { | ||
| **extra_requirements |
There was a problem hiding this comment.
This syntax is new in Python 3.5. If we need a copy of the dictionary, I think extra_requirements.copy() should work. I'm not sure that we do need a copy, though - I think you can just set them to the same object.
|
@takluyver do you or @Carreau have any idea about why this makes entrypoints unavailable? |
|
I don't know what was going on with entrypoints, but it seems to be working now. |
setup.py
Outdated
| 'serve': ['tornado>=4.0'], | ||
| 'execute': ['jupyter_client>=4.2'], | ||
| } | ||
| extra_requirements['all'] = sum(extra_requirements.values(), []) | ||
| extras_require = setuptools_args['extras_require'] = extra_requirements |
There was a problem hiding this comment.
I don't think we need to have this called both extra_requirements and extras_require. There's nothing in the code after this using it by either name; its only in setuptools_args that it's used.
In the process of making a release, thought I'd add some better documentation (rather than just following a hodgepodge of notebook and ipython release docs, and also wanted to add explicit checks for the version number to avoid nonvalid version numbers that have caused problems in the past.
@Carreau I figure you'll care the most of everyone about this.
Just want to get this settled and then I'll make the next release. I have these thoughts every time I want to make a release and this time I just wanted to deal with some of the loose ends that are always left dangling before making the actual release.
Also, technically we weren't using a pep440 compliant version number before I don't know why it wasn't causing a problem but hey, no harm in doing so just briefly before releasing.