How can separate packages load core without conflict?

[quartzmo]

As we modularize into separate packages (see #813), we must ensure that separately-loaded gems' dependencies on google-cloud-core never conflict.

I am guessing that we must simply guarantee that google-cloud-core is always backwards-compatible. Failing that, we must move behavior that is not backwards-compatible to a new namespace. Any other ideas?

[blowmage]

When we've discussed this before, we agreed that core will never conflict. So any change in behavior will have to be made in a backwards compatible way. Right now, the only things in core are the initial constructor, (Google::Cloud.new), the main credentials class, and the error classes.

[quartzmo]

Great, just wanted to make sure about our explicit commitment here.

/cc @jgeewax

[jgeewax]

I agree that we need to follow this rule for the global constructor, but I thought we also settled that we'd put other stuff (ie, common iteration logic) in there that was common rather than repeating ourselves... If we don't, we're setting ourselves up for mistakes where common_method_1 in one library is different than another - which is bad....

So given we'll have common logic in this core package, we need a way to make sure that the single package knows multiple versions worth of that logic, and saying "we just will always be backwards compatible" seems like an iffy way of doing this.

The only suggestion I've heard so far that seems legit has been to use "path versioning" where I have v1::common_method_1 and ``v2::common_method_1and my other packages can use those as needed. I expect these to be different, whereas I don't expectdatastore::common_method_1` to be any different from `pubsub::common_method:1`.

I'm open to other options, but as mentioned several times, breaking DRY and putting multiple copies of common logic in different packages seems like we're digging ourselves another hole. And just saying "we won't let it get out of hand" seems prone to accidental failure.

[blowmage]

Yes, this is what we discussed before. One example would be the incremental backoff, which is already replaced by Google API Client for JSON APIs, and will soon be replaced by GAX for GRPC APIs. We would have a common implementation of backoff as Backoff#execute, and if we needed some backwards compatible change we would introduce a new method such as Backoff#execute2. Or, if the change needed required a new class we could introduce Backoff2#execute. But this is all internally shared logic and not part of the public API.

The other non-public shared logic in core is check for the Google Compute Engine project_id, and some utility methods for converting to/from common Protobuf objects.

[quartzmo]

I think we are all in agreement as to how to manage breaking changes, as there are not a lot of options. What @jgeewax calls "path versioning", I call "a new namespace" and @blowmage calls "a new class".

@jgeewax I agree with your recommendation to aggressively refactor duplicated code to the core library.

[blowmage]

Gonna close this. Please reopen if there are more questions.