On Thu, Jul 24, 2014 at 12:59 AM, roger peppe <[email protected]> wrote:
> 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. > WTF? We have charm.InferURL *and* charm.ParseReference for the cases where sloppy input is reasonable -- charm.ParseURL should *parse a URL*, and fail if not given a string that represents a URL. And ServiceDeploy should *definitely* not accept sloppy input: I'm certain we had exactly this argument back in the early API days, and looking at the code STM to imply that a reasonable attempt was made to follow my instructions -- ie ServiceDeploy will fail if the charm revision is not specified, as it *should* if the schema or series or anything else is left unspecified. Anyway, someone changed some code and introduced a bug that got missed in review; it happens. However, someone now needs to go into the charm package and add some tests to ParseURL to ensure it errors as it should when schema, or series, is omitted. Note that not even charm.URL is itself currently necessarily fully > specified - the revision can be omitted. > It's a valid charm URL with or without a revision. It is *not* a valid charm URL without a schema, series, or name. These definitions have not changed in years. 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. > This makes me shudder -- why would we want to encourage distribution of a format encoding vague guesses as to validated best practice, rather than encoding *actual* validated best practice? `juju deploy foo` is great for demos and exploration, but I'd expect any serious user to value reproducibility enough to specify the actual charm precisely; and for them to expect that the bundles they use would do the same. > 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? > Fuzziness over the meaning of URL appears to have already broken ParseURL, and hence ServiceDeploy; let's not double down on that. Even if the bundle format's sloppiness is already entrenched, that's no reason for juju-core to give up and just start accepting whatever -- the clients can damn well rewrite sloppy bundles before using them with juju, just as they should, and do (or at least *did*... who knows what's happened recently since validation got broken) rewrite sloppy charm URLs before passing them to juju. Cheers William
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
