On Sun, Dec 11, 2016 at 12:57:35PM -0800, Mark Shuttleworth wrote: > On 05/12/16 07:12, Colin Watson wrote: > > As suggested in this thread and on IRC, I fell back to accepting > > zero-sized resources instead and uploading those to the store, and that > > works OK: > > > > https://jujucharms.com/u/launchpad/launchpad-buildd > > > > It seems like a fairly nasty hack though. Resources are pretty nice, > > and this feels like a wart. > > I think the point is that "juju deploy foo" should always give you a > reasonable result. In your case, that's the PPA option. *if* a resource > is specified, then it should be used. What we want to avoid is charms > which don't work at all unless a resource is specified.
Right, I can definitely see that, and ensuring that there's always a reasonable result is exactly what I'm trying to do. I'm not sure that the current mechanism particularly helps with that, though. Charm authors can still easily upload a zero-sized resource to the store and then have their charm refuse to do anything unless you attach a "real" resource. If we assume that authors will legitimately want some way of doing optional resources (it seems like a handy way to have a payload which normally comes from some centralised source but which you might instead attach directly for quick iteration during development), then the zero-sized resource thing seems likely to become a fairly widespread pattern that people will copy. Given that, making authors resort to non-declarative hacks to achieve the goal of an optional resource might just increase the chance of mistakes. I can see how resources should default to being required at the charm store level to avoid making it easy to publish broken-by-default charms by accident. But how about something like this: * Add an "optional: true" option to resources, which the charm store would interpret as allowing a charm to be released without that resource. * Add some kind of affordance to charm-helpers to make this easy to use correctly. For instance, resource_get might be changed to take a "default" parameter, which would be accepted and required iff the resource in question is optional, or something along those lines. * Perhaps also add something to layer-apt and layer-snap to encapsulate the "install from this source by default, but use a resource if it's attached" pattern. I don't have a broad enough view of charms to be able to tell whether this is a good idea in general or overkill, but it would certainly have saved me some effort the other day if I could have just written something like this instead of a bunch of reactive code that took me several tries to get right: options: apt: packages: - launchpad-buildd - bzr-builder - git-build-recipe - quilt optional-package-resources: - launchpad-buildd - python-lpbuildd -- Colin Watson [cjwat...@ubuntu.com] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju