[Marc-Andre-Rivet]

Fixes #995

Manually tested against

1. Custom table build with version

  "version": "4.5.1-alpha1.2.3+metadata.1.2.3-abc",

2. The modified version of the @plotly/webpack-dash-dynamic-import plugin

3. 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)

[alexcjohnson]

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.

[Marc-Andre-Rivet]

[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 🤷‍♂

[Marc-Andre-Rivet]

Alright.. let's go full pathological.

[alexcjohnson]

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. 💃