You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should use a scheduled CI workflow that regularly (e.g. weekly) checks for a new version of the tzdb and automatically publishes a new version to pypy if there is one. This needs some minor changes to the update.py script to automatically pick up the version of the downloaded tzdb data files. Furthermore update_zoneinfo.py curently uses an unreleased ics.py version to parse the vTimezones, check whether there are any non-trivial changes, and only copy them with their new IDs if that is the case. As this requires ics.py v0.8, which in turn might depend on this project, we kind of have a cyclic dependency - which is easy to solve when running manually, but might force the automated workflow to be deferred until after 0.8 is out.
Side node: publishing to PyPy could allow introducing arbitrary code, which would then be delivered to and executed by anyone who uses this library, so special care needs to be taken to not introduce any possibilities for an attack, e.g. by only publishing changes from the master branch (compare ics.py#274).
The text was updated successfully, but these errors were encountered:
We should use a scheduled CI workflow that regularly (e.g. weekly) checks for a new version of the tzdb and automatically publishes a new version to pypy if there is one. This needs some minor changes to the
update.py
script to automatically pick up the version of the downloaded tzdb data files. Furthermoreupdate_zoneinfo.py
curently uses an unreleasedics.py
version to parse the vTimezones, check whether there are any non-trivial changes, and only copy them with their new IDs if that is the case. As this requiresics.py
v0.8, which in turn might depend on this project, we kind of have a cyclic dependency - which is easy to solve when running manually, but might force the automated workflow to be deferred until after 0.8 is out.Side node: publishing to PyPy could allow introducing arbitrary code, which would then be delivered to and executed by anyone who uses this library, so special care needs to be taken to not introduce any possibilities for an attack, e.g. by only publishing changes from the master branch (compare ics.py#274).
The text was updated successfully, but these errors were encountered: