Proposed API Change - Get default repo/namespace from environment variable.

Clint Byrum clint at
Tue Feb 28 23:16:57 UTC 2012

Excerpts from Gustavo Niemeyer's message of Tue Feb 28 14:47:09 -0800 2012:
> On Tue, Feb 28, 2012 at 19:38, Kapil Thangavelu
> <kapil.thangavelu at> wrote:
> > Series is a little different. Its specified/required in the environments.yaml.
> Not really.. that was a temporary hack that must die before 12.04.

I think we've discussed this before, but how does one infer the series
without the default-series in environments.yaml? Perhaps we should not
infer one ever, and just tell the user that they need to specify the
series, if it is not set that way.

In the past it was suggested that a sane default is the release of
ubuntu your client juju is running on. I don't consider this valid or
even useful at all. When Q releases, people will upgrade their laptops
to it, but they won't want to start having their services run on top
of Q, at least, not without asking for it. Also this leaves a natty,
OS X or Debian user of the client with a different set of requirements
in environments.yaml than somebody on oneiric or precise.

So, while I support getting rid of the hard requirement, I think the
user experience needs to be carefully changed to guide users to the
correct behavior they desire.

> > The other options here are just additional parameterization of existing cli
> > options.
> All of the default namespace, as proposed, is just parameterization of
> the namespace used in the command line. No further semantic changes
> are implied in addition to what was already agreed on.
> > ie. including series means collapsing two configuration items into a single
> Series is already a property of the charm URL, and that was the plan
> since we first discussed series. Are you just now realizing that? I'm
> a bit concerned now.

To me, what Kapil was saying was that we need a way to infer that series
reliably, and right now the only reliable way is the environments.yaml
setting.  So if you also then have people inferring it from the
environment, the whole thing gets less clear.

That said, I agree with your proposed solution, and don't think this
will be inviting conflicts. We simply should make it required in all
charm operations if it is not specified in environments.yaml or the
environment variable.

All of that said, we can make this change (adding the ability to set the
full inferred charm namspace by environment variable) without fixing that.

More information about the Juju mailing list