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
The number of patches, their purpose, and their state (proposed to be merged to core or not) across the extensions is not generally known.
Since here we have the registry of extensions, we can centralize harvesting of those patches and creating a table here. Could annotate with versions when patches were introduced, their descriptions etc. But it likely to be useful only in case if we add extra metadata there as is the patch intended to be merged upstream and in what version it was etc.
WDYT?
The text was updated successfully, but these errors were encountered:
Even without additional metadata this can make sense. The extensions that do patching, do it via an explicit import in <root>.patches.enabled. From that file, things are discoverable.
We (well, the https://github.com/datalad/datalad-next/blob/main/datalad_next/patches/__init__.py#L10) have "patch system" in DataLad where extensions might patch core functionality.
The number of patches, their purpose, and their state (proposed to be merged to core or not) across the extensions is not generally known.
Since here we have the registry of extensions, we can centralize harvesting of those patches and creating a table here. Could annotate with versions when patches were introduced, their descriptions etc. But it likely to be useful only in case if we add extra metadata there as is the patch intended to be merged upstream and in what version it was etc.
WDYT?
The text was updated successfully, but these errors were encountered: