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
Since Python modules are installed in a global namespace, breaking changes to APIs can be very difficult to deal with, especially in a toolbelt like this one, since it's intended to be used by whole ecosystems of packages. If a breaking change is introduced here it needs to be updated at every point in the dependency tree, all at once, which is challenging.
I don't want to freeze the API forever, so instead the solution should be to provide a stable compatibility layer for libraries. For example, instead of import vg, a library would use import v1 as vg from vg. That way, libraries will be inured to future breaking changes, so long as 1.x or later version is used.
Convenience for application code means that import vg will keep working, and use the latest version.
It could also be possible to import next as vg from vg to provide experimental APIs before they've reached a point of stability.
I'd like to include this before the next major version is released.
The text was updated successfully, but these errors were encountered:
Since Python modules are installed in a global namespace, breaking changes to APIs can be very difficult to deal with, especially in a toolbelt like this one, since it's intended to be used by whole ecosystems of packages. If a breaking change is introduced here it needs to be updated at every point in the dependency tree, all at once, which is challenging.
I don't want to freeze the API forever, so instead the solution should be to provide a stable compatibility layer for libraries. For example, instead of
import vg
, a library would useimport v1 as vg from vg
. That way, libraries will be inured to future breaking changes, so long as 1.x or later version is used.Convenience for application code means that
import vg
will keep working, and use the latest version.It could also be possible to
import next as vg from vg
to provide experimental APIs before they've reached a point of stability.I'd like to include this before the next major version is released.
The text was updated successfully, but these errors were encountered: