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

Added argument to param.Version to support dev versions #200

Merged
merged 5 commits into from
Oct 4, 2017

Conversation

jlstevens
Copy link
Contributor

Added dev argument that allows dev versions to be handled like regular release versions. I'm happy to add more unit tests to make sure everyone is satisfied with this addition.

@coveralls
Copy link

coveralls commented Oct 4, 2017

Coverage Status

Coverage decreased (-0.2%) to 74.747% when pulling 1404048 on dev_versions into d79eab1 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.4%) to 74.495% when pulling 1404048 on dev_versions into d79eab1 on master.

@jlstevens
Copy link
Contributor Author

I'll definitely add enough unit tests to make sure test coverage increases instead of decreasing.

param/version.py Outdated
@@ -233,6 +243,7 @@ def __str__(self):
"""
if self.release is None: return 'None'
release = '.'.join(str(el) for el in self.release)
release = '%sdev%d' % (release, self.dev) if self.dev else release
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't there be a "." before "dev" by PEP440?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it is fine, this is a snippet Bryan posted:

In [1]: from packaging.version import Version as V

In [2]: V("0.12.10dev3")
Out[2]: <Version('0.12.10.dev3')>

In [3]: v = V("0.12.10dev3")

In [4]: v.is_prerelease
Out[4]: True

In [5]: v.base_version
Out[5]: '0.12.10'

In [6]: v > V("0.12.11")
Out[6]: False

That said, I am happy to consider adding the dot - even though our existing dev tags don't have the dot, they have all been lightweight tags so far (and therefore have no effect on param.Version).

@philippjfr Do you want the dot?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we aren't worried about people referencing the old tags (I'm not - they are dev versions!) then I could go back and replace the old dev tags with the new format.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alternatively, we can delete the tags for old dev versions that have been followed by a release. Then we can use the new format going forwards.

Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer to leave out the dot personally, bokeh does too.

@jbednar
Copy link
Member

jbednar commented Oct 4, 2017

Looks fine by me apart from comment above.

@ceball
Copy link
Member

ceball commented Oct 4, 2017

I am also ok with this.

Thanks a lot for doing it. Despite the jokes, I appreciate it. (I will try to come up with new versions of the jokes.)

Seems unfortunate that it's necessary to support both with and without the dot

  • to match PEP 440 (dot MUST be there) and its implementation in packaging ("normalized" form has dot, but the dot is optional)
  • to match what's out there (see below)

Examples off the top of my head...

No dot:

  • holoviews
  • bokeh
  • datashader

Dot:

  • packaging
  • pandas
  • numba

@jlstevens
Copy link
Contributor Author

@philippjfr @ceball @jbednar

I added a pep440 flag we can use to stick to the devX format instead of the PEP440 .devX format. If you agree with this approach, I'll add more unit tests and update the docstrings to explain this option.

@coveralls
Copy link

coveralls commented Oct 4, 2017

Coverage Status

Coverage decreased (-0.1%) to 74.763% when pulling fb28248 on dev_versions into d79eab1 on master.

@coveralls
Copy link

coveralls commented Oct 4, 2017

Coverage Status

Coverage decreased (-0.2%) to 74.732% when pulling 62012e1 on dev_versions into d79eab1 on master.

@coveralls
Copy link

coveralls commented Oct 4, 2017

Coverage Status

Coverage increased (+0.5%) to 75.362% when pulling 4eb324a on dev_versions into d79eab1 on master.

param/version.py Outdated
@@ -233,6 +249,8 @@ def __str__(self):
"""
if self.release is None: return 'None'
release = '.'.join(str(el) for el in self.release)
release = ('%s%sdev%d' % (release, '.' if self.pep440 else '', self.dev)
if self.dev else release)
Copy link
Member

Choose a reason for hiding this comment

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

Do people do dev0 (thinking along the lines of 0 being false above)? Actually, I realize now I have seen e.g. 1.x.dev (numba, pandas). But we can't support everything, and I think just .dev doesn't comply with PEP 440 ("The developmental release segment consists of the string .dev, followed by a non-negative integer value").

This is all getting a bit crazy, sorry...

@jlstevens
Copy link
Contributor Author

I think I'll go with a suggestion from @jbednar - support tags with and without the dot and return the version string with the dot. Then you have the flexibility for tagging while using the PEP440 compliant version strings.

@coveralls
Copy link

coveralls commented Oct 4, 2017

Coverage Status

Coverage increased (+0.5%) to 75.378% when pulling 42be059 on dev_versions into d79eab1 on master.

@ceball
Copy link
Member

ceball commented Oct 4, 2017

Looks ok to me, thanks :)

@jbednar jbednar merged commit 64c8f7c into master Oct 4, 2017
@jbednar jbednar deleted the dev_versions branch October 4, 2017 23:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants