On 11/12/16 13:42, Colin Watson wrote: > I'm not sure that the current mechanism particularly helps with that, > though.
Yes, I agree, because it's hard to know what 'reasonable result' looks like in code :) > 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. Yes, agreed. > 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 > These are great suggestions. I think in the end what we want is to hold the "works without a separate CD" requirement for the curated set, where we manually review. But making resources optional seems like the sensible avoid-hacky-workarounds-becoming-standard approach here. Mark -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
