[Meta] What to do when a dependency update includes breaking changes?

[FichteFoll]

Currently, dependencies are guaranteed to stay on at least the latest available version at the time of package installation or upgrade. That means a breaking change in the package that requires a new version of the dependency will get fixed along the installation (pending #1069).

However, if a dependency updates without the package, for example when the package author is AWOL or the dependency author just updated its dependency by himself, then the package will just break on the next restart.

Because Package Control will very likely not receive advanced dependency resolution (because that is truly costly), I am wondering how else we could prevent sitations like these. Keep in mind that global states must be avoided because of multiple package potentially requiring different versions of a dependency.

At this moment, I have the following options in mind:

1. Provide the dependency under a new dependency name (and new module name also) for breaking changes. Think of urllib2 and urllib3. Only downside is that import statements will look like import library12 as library at some point.
2. Very similar to 1, but provide all versions of the dependency under different module names in the same package.
3. Single dependency and module, but add a method/function that accepts a version number and returns the API of that version. This would have to be implemented dependency-specific and is probably a lot of work. It would also have to be implemented for all sub-modules and generally be very annoying.

I think 1 is the best so far, with 2 closely following (less metadata but potentially more unused junk). 3 just seems infeasable.

Opinions? Suggestions?

[wbond]

This is an area I think Package Control is going to punt on. The author of the dependency will need to communicate with the package authors to figure out what to do.

This issue will likely only be present for rapidly moving pure-Python packages (I am thinking of requests specifically).

My person approach in this area is to embed libraries to prevent conflicts with other packages and so I can apply my own bug fixes. This works in concert with how I used dependencies, which is to prevent large binary downloads of shared libraries/compiled modules with every new package version.

[FichteFoll]

This question wasn't specifically targetted at you or as an issue of package control, but I appreciate the attention anyway. Maybe I should put this on the forum instead.

The reason I ask is because I want to split the sublime_lib module filled with utility functions and classes from PackageDev, change it somewhat and submit as a dependency. Breaking changes will probably not occur to often, but if they do I would like to have a plan ahead already.

I agree, bundling your dependencies will usually assure you are working with the appropriate version, but I am unsure at this moment if this is also the case in ST2 tbh, since you use absolute imports for root packages and many people also mess with sys.path for their bundled packages (because these use absolute imports internally, brrr). This territory is largely unexplored and package control's dependencies are actually more reliable - if they were used by everyone.

[FichteFoll]

This really is a problem to be solved by dependency authors and shouldn't be here imo. Closing.