Version attribute does not encode development status

[mwaskom]

I was trying to do some version-conditional monkey patching to test out the new feature in https://github.com/jupyter/nbclient/pull/130 (thanks!), but it looks like the nbclient.__version__ attribute does not distinguish development status such that, with an install of current master HEAD,

import nbclient
from packaging.version import Version
Version(nbclient.__version__) <= Version("0.5.1")

returns True.

I was expecting something like 0.6.0.dev0, such that the test would evaluate to False.

Feel free to ignore if this approach is a considered decision.

[MSeal]

Some of the jupyter project add the dev version to master -- it's a little annoying to get bumpversion to handle it the right way so it wasn't done at first. No objection to adding that if someone has a will.

For now how about I just do a quick patch release for you.

[MSeal]

0.5.2 is on PyPI now (conda to follow whenever the automation runs)

[choldgraf]

My general preference is "make it super easy and non-problematic to cut patch releases (or alpha releases)" over using dev0 patterns in the versions, but I'm open to other approaches!

[davidbrochart]

0.5.2 is on PyPI now (conda to follow whenever the automation runs)

Thanks Matthew, I didn't finish the job.

[mwaskom]

For now how about I just do a quick patch release for you.

👍 👍 👍 👍

Thanks! That solves my actual issue perfectly.

Hi @choldgraf. No opinion on best approach here ... agreed that it can make life a little difficult (I, a luddite, still update all my version strings manually). Feel free to close if you find this way works best for you.

[MSeal]

For what it's worth, when I am deving I just always do pip install -e . in the unreleased checkout of a repo I want to use. No version fuss and just what-I-have-locally until I uninstall the local library.

[choldgraf]

yeah same here, though it sounds like @mwaskom was doing conditional logic based on version in his own library, which sounds a bit more complex and why he needed a different version to work from

[choldgraf]

I, a luddite, still update all my version strings manually

pssshhhhh do you even #datascience bro?

[mwaskom]

it sounds like @mwaskom was doing conditional logic based on version in his own library

right, the context here is that we use nbconvert in a github action workflow and I wanted to update that now with a forward compatibility layer that would monkey-patch NotebookClient until the next version was released ... probably a fairly esoteric usecase.

pssshhhhh do you even #datascience bro?

yes because i need to update the version in both setup.py and __init__.py, so I run that in parallel with spark ;)