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

Create an upgrade schematic for third party libraries to bridge breaking versions #20

Open
apryor6 opened this issue Aug 23, 2019 · 0 comments

Comments

@apryor6
Copy link
Owner

commented Aug 23, 2019

An incredibly useful feature of the Angular CLI is ng-update, which provides a modification schematic for rewriting broken APIs as you upgrade across version of a library. The mechanism by which it works is that third party libraries provide a schematic with a special name, and then the ng-update command looks into the project for that schematic and executes it.

We could easily implement such a hook in flaskerize like fz update <package_name> that would really be just an alias for fz generate <package_name:fz_update> or something similar (here I have implicitly proposed that fz_update be the default schematic name.. doesn't need to be).

The implications of this functionality are profound. If these update schematics were incorporated into pip upgrade, it would be possible for library authors to relentlessly make breaking changes in their libraries without any concern for backwards compatibility provided that there was a schematic-upgrade path to migrate across versions. Enormous time and resources could be saved that are currently spent on managing long-term deprecation cycles as outdated parameters and APIs are moved. Instead, we would be moving towards a philosophy of forward-compatibility. This also puts the mental burden of bridging from an old library API to a new one on the library developers first and the consumers second, rather than the other way around.

Implementing this in flaskerize would involve customizing the run method to recurse through the project source code and modify regions that use the outdated/broken API to use the new one. The exact mechanics of what this involves would depend on the nature of the upgrade (again, this is why it would be best to leave this up to the library developers as they implement their own fz_update schematics). However, it will almost surely be necessary for flaskerize to expose helper methods for modifying source code to empower the developers to accomplish this, as the details of source code modification are quite complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.