search

juju / charm-tools

Tools for charm authors and maintainers
Other
42 stars 64 forks source link

Support forks of interfaces #230

Open stub42 opened 8 years ago

stub42 commented 8 years ago

There is one true implementation of an interface registered at interfaces.jujusolutions.com. 'charm build' will pull from a local directory in INTERFACES_PATH, or the one true implementation. This makes it difficult for charms that need to use a fork of an interface, as they need to maintain this dependency somehow so 'charm build' can generate a valid charm.

It would be great if a branch could be specified in layer.yaml, specifying the branch to use instead of the one registered on interfaces.jujusolutions.com.

This is probably a small discrete chunk of the larger https://github.com/juju/charm-tools/issues/212

marcoceppi commented 8 years ago

Why would you want to fork an interface, the whole idea about interfaces is that they shouldn't be forked otherwise we end up with the http interface all over again.

On Mon, Jul 11, 2016 at 3:53 AM stub42 notifications@github.com wrote:

There is one true implementation of an interface registered at interfaces.jujusolutions.com. 'charm build' will pull from a local directory in INTERFACES_PATH, or the one true implementation. This makes it difficult for charms that need to use a fork of an interface, as they need to maintain this dependency somehow so 'charm build' can generate a valid charm.

It would be great if a branch could be specified in layer.yaml, specifying the branch to use instead of the one registered on interfaces.jujusolutions.com.

This is probably a small discrete chunk of the larger #212 https://github.com/juju/charm-tools/issues/212

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/juju/charm-tools/issues/230, or mute the thread https://github.com/notifications/unsubscribe/AAET1dTd_Acq5mMf6NssnhtAfxJDjD6Aks5qUfaRgaJpZM4JJHRV .

stub42 commented 8 years ago
johnsca commented 8 years ago
  • Because different people have different ideas about the API.
  • Because there will be backwards incompatible changes.

These are the exact cases where we explicitly want to prevent forking. Lest, as @marcoceppi mentioned, we end up back in incompatible interface hell.

  • Because it takes time to land changes, but changes are needed immediately
  • Because we want to test updates on a canary project for a while before publishing it for all charms.

If we preclude the first two cases, then changes should be much easier to land. We should also encourage (and provide templates for) 100% test coverage for interface layers to make landing changes even easier with better confidence.