On 23 July 2014 11:51, John Meinel <[email protected]> wrote: > 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".
Luckily there are no APIs that currently take a URL type as an argument. The only ones that do (ServiceDeploy, for example) currently use a string, because they allow a partially specified URL, so can't use charm.URL. Note that not even charm.URL is itself currently necessarily fully specified - the revision can be omitted. On 23 July 2014 13:01, Gustavo Niemeyer <[email protected]> wrote: > On Wed, Jul 23, 2014 at 7:35 AM, roger peppe <[email protected]> wrote: >> 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. > > That sounds slightly surprising. How do we plan to define what the > bundle actually means? The charm URL in a bundle means exactly what it would mean if you typed it in a juju deploy command. That is, it is dependent on the charms available at bundle deploy time. An unspecified revision uses the latest available revision; an unspecified series uses the latest LTS series that's available for the charm. > As noted above, a Reference may not have a schema as well, so this > suggestion seems to imply that "foo" becomes a valid URL. Yes, both ParseURL and ParseReference both already allow the schema to be omitted, defaulting to "cs:" if so. > Maybe having just URL could be made cleaner, though. This should > be judged based on a more detailed proposal. I do believe having just URL would be significantly cleaner. What area would you like to see more detail on? cheers, rog. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
