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

Issue 995 - Correctly support version-prerelease+metadata in fingerprint #999

Merged
merged 6 commits into from
Nov 4, 2019

Conversation

Marc-Andre-Rivet
Copy link
Contributor

@Marc-Andre-Rivet Marc-Andre-Rivet commented Nov 4, 2019

Fixes #995

Manually tested against

  1. Custom table build with version
  "version": "4.5.1-alpha1.2.3+metadata.1.2.3-abc",
  1. The modified version of the @plotly/webpack-dash-dynamic-import plugin

  2. App, with both eager_loading true / false to trigger async resources from both DashPy and the plugin

import json
import pandas as pd
from datetime import datetime

import dash
from dash.dependencies import Input, Output, State
from dash.exceptions import PreventUpdate

import dash_table
import dash_core_components as dcc
import dash_html_components as html

app = dash.Dash(__name__, eager_loading=False)

app.layout = html.Div([
    dcc.DatePickerRange(
        id="date-picker-range",
        start_date_id="startDate",
        end_date_id="endDate",
        start_date=datetime(1997, 5, 3),
        end_date_placeholder_text="Select a date!",
    ),
    dash_table.DataTable(
        columns=[],
        data=[]
    )
])

if __name__ == '__main__':
    app.run_server(debug=False)

Marc-André Rivet added 2 commits November 4, 2019 10:24
- DashPy `+` fix
- additional test for version-pre+meta case
@Marc-Andre-Rivet Marc-Andre-Rivet marked this pull request as ready for review November 4, 2019 15:35
Marc-André Rivet added 2 commits November 4, 2019 10:39
@Marc-Andre-Rivet Marc-Andre-Rivet changed the title Correctly support version-prerelease+metadata in fingerprint Issue 995 - Correctly support version-prerelease+metadata in fingerprint Nov 4, 2019
@@ -9,7 +9,7 @@ def build_fingerprint(path, version, hash_value):

return "{}.v{}m{}.{}".format(
"/".join(path_parts[:-1] + [filename]),
str(version).replace(".", "_"),
str(version).replace(".", "_").replace("+", "__"),
Copy link
Collaborator

Choose a reason for hiding this comment

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

This works for +, but how confident are we that +, -, and . are the only characters outside of \w ([A-Za-z0-9_]) that we're ever going to see? Is there anything to stop people from making a package with
__version__ = "the $%# *best* apple π"?
and then, to be ultra-paranoid, their next version is:
__version__ = "the $@# *best* apple π"
Or perhaps more likely, some foreign character used as a serial number gets incremented to the next such foreign character.

Feels to me the super-safe way to handle this would be to replace each [^\w-] character with an escape code, something like "_{:x}".format(ord(char)). If we want to keep . as just _ that seems pretty safe, even if there could be a pathological case that breaks it - in fact starting with any unescaped character then replacing it with itself escaped in the next version (including, today, replacing _ with .) would yield a matching string... but I'd be willing to ignore that possibility.

Copy link
Contributor Author

@Marc-Andre-Rivet Marc-Andre-Rivet Nov 4, 2019

Choose a reason for hiding this comment

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

[0-9a-zA-Z] and - are the only allowed characters in the fragments as per semver.
https://semver.org/

Versions need to be non-negative numbers.
Pre-release begins with - with n-fragments separated by .
Metadata beings with + with n-fragments seperated by .

Checking out what https://www.python.org/dev/peps/pep-0440/ expects.. turns out they also support version epoch which would add ! into the mix (https://www.python.org/dev/peps/pep-0440/#id30)

Is there anything to stop people from making a package with "$%# best apple π"

Yes. [0-9a-zA-Z] and - is pretty much what's allowed for both npm and pypi semver.

Although.. maybe some other distribution channel does not follow the same underlying norm npm/pypi follow, for some reason. If that happens, we might have to uri encode those strings too 🤷‍♂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright.. let's go full pathological.

Copy link
Collaborator

@alexcjohnson alexcjohnson left a comment

Choose a reason for hiding this comment

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

Yep, that'll work. If anyone comes back asking us to actually distinguish [^\w-] characters so they cache independently, the onus is on them to show that this is in the spirit of some common version scheme. 💃

@Marc-Andre-Rivet Marc-Andre-Rivet merged commit 1678e7d into dev Nov 4, 2019
@Marc-Andre-Rivet Marc-Andre-Rivet deleted the 995-fingerprint-metadata branch November 4, 2019 17:19
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.

[BUG] + in version string breaks fingerprint system
2 participants