Hide resources from showing on the store

[Mark Shuttleworth]

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