series-agnostic charm URLs

John Meinel john at arbash-meinel.com
Wed Jul 23 10:51:44 UTC 2014


Casey is the one to talk to. I'm not sure if he was just trying to be
conservative, but he did intentionally not want to pun the types. I think
he wanted to be clear that things passed to *these* API calls must be fully
formed, while ones passed to *those* could be expanded.
We could do what you say, but it starts meaning every API that takes a URL
has to start worrying about expanding it late.
Since it is no longer "charm.URL" but really "charm.MaybeURL".

John
=:->


On Wed, Jul 23, 2014 at 2:35 PM, roger peppe <roger.peppe at canonical.com>
wrote:

> In the charm store and the bundle specification, we use both fully
> specified charm URLs (with series) and partially specified charm URLs
> (without series and/or version).
>
> Currently in the charm package, the charm.URL type represents the
> former, the charn.Reference type represents the former; but there is
> no type that
> can represent both forms.
>
> We want to store charm URLs in mongo-db that are agnostic whether
> the series is specified or not. For example, in a bundle, a service
> is free to specify a series in the charm name or not.
>
> I'd like to suggest that we remove the Reference type and use the URL
> type throughout, allowing it to have an unspecified series
> where the string form does not specify a series.
>
> This means that the URL type would be an exact reflection of the string
> form of a charm URL.
>
> We would add a ParseFullURL method which is like ParseURL
> currently - it would check that the series is fully specified. All
> occurrences of charm.ParseURL in juju-core would be changed to use
> charm.ParseFullURL. All occurrences of ParseReference would change to
> use ParseURL.
>
> This would change the semantics of URL unmarshaling,
> but the Juju API does not currently rely on that.
> There is at least one place (params.ServiceDeploy) where
> we would now be able to use a *charm.URL rather than
> a string.
>
> The changes required in juju-core are largely mechanical,
> and generally make things simpler.
>
> Does this sound reasonable?
>
>   cheers,
>     rog.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140723/dab1f4c0/attachment.html>


More information about the Juju-dev mailing list