On 23 July 2014 11:51, John Meinel <j...@arbash-meinel.com> 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 <gust...@niemeyer.net> wrote:
> On Wed, Jul 23, 2014 at 7:35 AM, roger peppe <rogpe...@gmail.com> 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
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
