[06:08] morning. [07:02] fwereade: mornin'! [07:13] fwereade: ping [07:15] rog, heyhey! [07:15] rog, nice holiday? [07:15] fwereade: lovely, thanks, although the weather... left something to be desired [07:16] fwereade: i'd forgotten just how lovely and wild cornwall actually is [07:16] rog, ha, yes, I have been hearing such reports [07:16] rog, lovely [07:16] fwereade: we had no problem finding places to park up "al fresco" [07:17] fwereade: i'm a bit sad though 'cos i managed to splash sea water on my phone on the last day and it's died [07:17] fwereade: losing some nice photos with it [07:17] rog, aw, bad luck :( [07:17] fwereade: and probably other stuff too that i haven't thought about. not to mention 300 quid's worth of phone :-( [07:18] fwereade: annoying thing is that all the stuff's probably still in there ok, i just can't get at it! [07:18] rog, quite so :( [07:18] fwereade: anyway, i was looking at environs/config [07:18] rog, well, I guess once it's dead you can take it to bits ;p [07:19] rog, ah, yes [07:19] fwereade: true, but i'll probably just find a flash chip - not easy to hook it up to anything [07:19] fwereade: there was a reason why parsing was separate from opening [07:20] fwereade: (gustavo seems keen to remove the distinction) [07:21] rog, cool, go on? [07:21] rog, wait I don't think that's what he wants [07:21] fwereade: no? [07:21] rog, getting a Config is still separate from getting an Environ and I expect it to remain so [07:21] fwereade: it looks to me like he wanted validaton to take place at Open time [07:22] " [07:22] The translation onto a struct type, though, and the further validation [07:22] of the configuration itself should still be done in the same style [07:23] done today, except inside EnvironProvider.Open. [07:23] " [07:23] fwereade: but perhaps i'm misunderstanding [07:23] rog, heh, perhaps I was too [07:24] rog, because I'm not sure what he means by "further" there [07:24] fwereade: i think he's suggesting that *all* the current validation take place in EnvironProvider.Open [07:25] fwereade: which means that if you have an environs config with several sections, each section will only be validated if you open it. [07:25] fwereade: i dunno, perhaps that's actually ok. [07:26] rog, I think that aspect particularly is in fact a win [07:26] fwereade: oh? [07:26] rog, I am still not 100% sold on the rest of it, but I am soldiering through and hoping all will become clear [07:27] rog, just because I have ballsed up the configuration of environment X I should not lose access to environment Y [07:28] fwereade: hmm, if that's what we want, then gustavo's comments make sense. although i'm not sure there's any need for a config type at all in that case. [07:29] fwereade: we can just use a map [07:29] fwereade: and i'm not sure when we'd ever use ValidateConfig [07:30] rog, ConfigSet.Get, env-set, secrets upload [07:32] rog, but, yes, I understand your reaction, the provider-internal struct types now seem pretty pointless [07:32] fwereade: could you expand on the above ( ConfigSet.Get, env-set, secrets upload) [07:32] rog, (and ValidateConfig does kinda assume that you can get a Config from an Environ in the first place) [07:33] rog, those are the times we want to change environment config [07:34] rog, but, well, I am not really in a position to give a robust defence of these choices [07:34] fwereade: we can easily change a config by setting elements in the map, i think. [07:35] rog, yeah, but those changes need to be validated somehow [07:35] fwereade: that's what EnvironProvider.SetConfig would do, no? [07:36] fwereade: ah, before we put the new config into the state? [07:36] rog, yeah, the idea is that the SetConfig is too late [07:37] rog, I dunno, this API does feel like it will be more awkward in some situations and less so in others [07:38] rog, I thought it was great having the EnvironConfig interface [07:38] fwereade: has any of the code for env-set or secrets upload already been written? [07:38] rog, not really [07:39] rog, I had the bulk of it written (and, I thought, quite nice), but... [07:39] fwereade: is the idea behind env-set that you can change any of the environ config settings live [07:39] ? [07:39] rog, some of them [07:39] rog, name, type, ec2 region etc must not change [07:40] fwereade: oh, and what's ConfigSet.Get ? [07:40] rog, ConfigSet is EnvironsConfig or whatever the environments.yaml-wrapper was called [07:41] rog, ie the point at which configs enter the system [07:42] fwereade: i see. i'm not sure how that relates to ValidateConfig though. [07:42] rog, ValidateConfig will be called as part of it (with nil for a first argument) [07:44] fwereade: hmm, i realise i don't understand how ValidateConfig is supposed to work [07:44] rog, I dunno, it really doesn't feel to me like it's been thought through properly, but I'm experiencing notable internal conflict between just-implement-what-was-asked-for and but-I-think-it-hasn't-been-thought-through-fully [07:44] fwereade: what's the "new" argument? [07:45] rog, it always validates new, and returns something based on it, with possible tweaks (ensure region is set; fix the authorized-keys-path malarkey) [07:45] rog, if old is not nil, it also checks need-to-be-immutable fields against old [07:46] ah [07:47] rog, it still doesn't feel quite like the right fit to me [07:48] * rog looks through code [07:48] Morning btw [07:48] rog, but I do not in general have niemeyer's foresight, so I am trying to reserve judgment and follow the spirit of what he seeks [07:49] TheMue: yo! [07:49] rog, if you wish to take it up with him I will observe thediscussion with great interest, though [07:49] TheMue, heyhey [07:49] rog: The two weeks are already over? [07:49] fwereade: AFAICS your environs/config proposal didn't have equivalent functionality to ValidateConfig, or am i missing something? [07:49] * TheMue thought it only has been one so far. [07:50] TheMue: yes, in the blink of an eye! [07:50] rog, no it didn't -- I was going to add a ValidateReplacement method to the EnvironConfig interface [07:51] rog, I felt that having providers only ever emit validated EnvironConfigs was a great feature [07:51] rog, now any bozo can create a *Config from whatever junk they have lying around in their scope [07:52] morning rog. [07:52] already back? :). [07:52] Aram: hiya [07:52] rog, hopefully it will be apparent enough that this is not actually a very helpful thing to do [07:52] fwereade: with niemeyer's proposal, i really don't see what advantage the config type has over just using a map. [07:53] rog, but it seems reasonably sane to have SetConfig call ValidateConfig under the covers anyway so we shouldn't e able to screw it up too badly [07:54] rog, I am not the right person to give helpful insight into the advantages of niemeyer's proposal [07:54] rog, perhaps it will suddenly click with me [07:54] fwereade: hmm, it does seem a bit like churn for the sake of it [07:54] rog, but it doesn't feel to me like the simplest or most expedient way to go about it [07:55] rog, well, what I *originally* wanted to was to have State.EnvironConfig and associated methods return and use actual EnvironConfigs [07:57] rog, and it's perfectly easy to do this, and to have real instances which I know for sure are valid, in every possible circumstance, bcause they're backed by a real struct type that can only be created by code inside that specific environ [07:58] fwereade: currently, there's no way of turning an EnvironConfig back into a map, i think. [07:58] fwereade: wouldn't that be a disadvantage of the above? [07:58] rog, yeah, but we need that one way or another and it's trivial [07:59] rog, the EnvironConfig itself can be responsible for producing a map that will unpack back to an identical instance [07:59] fwereade: it's just one more thing to get consistent (every time you add an environ field, you have to add code to go in the opposite direction) [08:00] fwereade: in gustavo's proposal, the translation is always one way, and i think that could work ok. [08:20] fwereade: network probs? [08:20] rog, apparently so [08:20] rog, did I miss anything? [08:20] fwereade: last two things i said: [08:20] [08:59:29] fwereade: it's just one more thing to get consistent (every time you add an environ field, you have to add code to go in the opposite direction) [08:20] [09:00:09] fwereade: in gustavo's proposal, the translation is always one way, and i think that could work ok. [08:21] fwereade: last thing i saw from you: [08:59:23] rog, the EnvironConfig itself can be responsible for producing a map that will unpack back to an identical instance [08:21] rog, ha, our timelines are somewhat divergent [08:23] rog, yeah, but we need that one way or another and it's trivial [08:23] rog, the EnvironConfig itself can be responsible for producing a map that will unpack back to an identical instance [08:23] rog, don't we have to do that regardless? [08:23] rog, they're stored in /environment as maps, so we have to have some way to turn a config into a map, like it or now [08:24] rog, I think it would be a really good thing if each env's idiosyncratic config-handling code were isolated behind a Config interface [08:24] rog, it seems to me that different static types for configs with very different behaviour is a good thing because we don't have to smoosh the config-handling code across various bits of the relevant Environ and EnvironProvider types [08:24] rog, as it is the only opportunity we have to turn it into a struct type is at SetConfig time, at which point its usefulness as a struct seems to me to be somewhat limited [08:24] * fwereade at this point looked at the code again and remembered something else, and went off along a new train of thought [08:25] rog, and now I'm not sure what to do about environments without secrets [08:25] rog, offhand it seems to me that an environ without secrets is not intrinsically an invalid thing [08:25] rog, ie you don't need to have secrets locally if the env already has them [08:25] rog, but maybe that's a case we don't care about [08:25] rog, hmm, do we have any rational basis for expecting the control-bucket to be public? [08:25] fwereade: do we expect it to be public? [08:26] rog, I didn't think so [08:26] rog, so that then means we *do* need auth to even get a StateInfo out of an environ [08:27] rog, and an Environ is not actually valid or useful in any way without its secrets [08:28] rog, this is inconvenient wrt possible future needs (let someone manipulate your env without giving them your AWS keys? can't be done) [08:28] fwereade: agreed. [08:28] rog, but maybe I should just not worry about that at the moment [08:28] rog, however this breaks my mental model a little [08:29] fwereade: there's no particular reason that it must be the *same* secret, i suppose [08:29] rog, I had been thinking the right thing to do was to allow an environ to exist without secrets, because I don't like the idea of an environ config delivered by the system that is not actually valid [08:29] rog, true, but that's still a bunch of stuff to manage [08:30] fwereade: when are we creating a partially valid environ? [08:30] rog, state.Initialize seems sensible [08:30] rog, IMO we should be pushing everything in the config that isn't a secret at bootstrap time [08:30] fwereade: why's that? [08:31] rog, consider default-series [08:31] fwereade: i have a suspicion that that might make several things more complex without much benefit, but please persuade me otherwise! [08:31] fwereade: go on [08:32] rog, if we start an env with a given default-series, and then change our environments config, it is IMO unhelpful to suddenly swap out the environment's default-series justbecause we're doing our first explicit deploy [08:33] fwereade: that's true of the environ secrets too. [08:33] fwereade: i think it might be more reasonable just to document that the environ config gets frozen at first deploy [08:34] rog, but there is a purpose to that and it doesn't lead to apparent random inconsistencies assuming the keys are validin the same situations [08:34] rog, so, env-set shouldn;t work until we've deployed? [08:34] fwereade: then we don't need to have anything that distinguishes secret from non-secret [08:34] fwereade: hmm. [08:35] fwereade: actually, i think env-set should work, but it should freeze the environment first [08:35] fwereade: so we could say that the first command *after* bootstrap freezes the env [08:35] rog, ok, actually, that works nicely [08:35] rog, kinda :/ [08:35] * fwereade arranges thoughts [08:36] rog, default-series in particular seems to me to act oddly there [08:36] rog, as an example of an env setting that has a tanglible effect on the bootstrap machine [08:37] fwereade: because it affects which bootstrap machine is chosen? [08:38] rog, and that it seems somewhat surprising to overwrite that arbitrarily, givn that the expectation want to set up, AIUI, is that environments.yaml settings will not be pushed by random operations [08:38] rog, and that changes to environments.yaml will not in general have any effect on a running environment [08:38] fwereade: i think that it's ok to say that bootstrap is special, and that environments.yaml is frozen on the first command after bootstrsap [08:39] fwereade: and that's a reasonable and comprehensible model [08:40] rog, I would prefer not to encourage the idea that it's sane or meaningful to alter environments.yaml after bootstrap [08:40] fwereade: otherwise people might well say "why is default-series different from aws secret keys?" [08:41] fwereade: i agree, but we do have the reality that we *have* to push some of the environ config after bootstrap [08:41] rog, because the secrets are unique in that we need them to do *anything* with the env, even get the bootstrap machine's id from the storage [08:42] rog, valid secrets are a prerequisite ofr doing *anything*; and so, transparently pushing known-valid secrets when none already exist in state prevents users from having to actually think about it at all [08:42] fwereade: am i right in thinking there's only one secret key that we need to push? [08:43] fwereade: (for ec2, at any rate) [08:43] rog, I guess the access key id is not technically a secret [08:43] fwereade: yeah [08:43] fwereade: here's a possible (maybe crackful) thought [08:44] fwereade: outside of environs, we just use map[string]interface{} [08:44] fwereade: then [08:45] fwereade: we provide EnvironsProvider.ValidateConfig(old, new map[string]interface{}) error [08:45] fwereade: and we say that any key containing the string "secret" is secret [08:45] fwereade: so it's trivial for provider-agnostic logic to filter out secret keys [08:46] fwereade: of course, this assumes that other provider types use the string "secret" in their secret keys... [08:46] rog, I have had thoughts roughly along those lines [08:47] rog, not specifically including the secret stuff [08:47] * fwereade reserves judgment [08:47] fwereade: if we go this way, then the environs/config package isn't required at all, i *think* [08:47] fwereade: oh no, it is [08:47] fwereade: to avoid the loop [08:47] fwereade: except... [08:48] fwereade: there's no need for state to call ValidateConfig [08:48] fwereade: so there's no need for a cyclic dependency. [08:48] fwereade: so no need for environs/config, i think. [08:49] rog, I think I may just be overly paranoid about people dumping random crap into /environments [08:49] rog, this is at the heart of my desire to have the state methods that manipulate environ configs work with actual environ configs [08:50] fwereade: we can still check that! [08:50] rog, but not within state [08:50] fwereade: state is internal [08:50] fwereade: we still have control over where the environ config gets into the system [08:50] fwereade: env-set [08:51] fwereade: environs.Open [08:51] etc [08:51] fwereade: and those places can do the checking [08:51] rog, so we have a bunch of state methods that validate what they're given, and one that pushes all responsibility for validation onto the various clients [08:51] fwereade: state methods validate what they can. [08:52] fwereade: we can state explicitly that the environment pushed into the state is not validated by the state [08:52] fwereade: that may even be a good thing actually [08:53] rog, ofc we can, doesn't stop it feeling sloppy to me [08:53] rog, we may as well say that state is internal and so there's no need to validate anything we put into it [08:53] rog, we can always trust the client code we write to do the right thing, after all [08:53] fwereade: it's a trade-off - i *think* that it's not worth creating a new package for [08:54] * fwereade maintains a studiously straight face [08:54] fwereade: there are lots of ways we can create invalid content inside state, i thinl [08:54] s/thinl/think/ [08:55] rog, like what? [08:56] fwereade: like we could do OpenPort("tpc", 45) [08:57] rog, instructive example [08:57] * fwereade ponders [08:59] rog, I think the distinction there is that there is no global source of truth we can use to validate against the set of protocols we know about elsewhere in the system [08:59] rog, in the environment case we can do so, and it doesn't feel like much work to me [09:00] rog, but look, this is not an especially productive conversation because I keep falling back to describing my own perspective on the problem [09:01] rog, which is to all intents and purposes irrelevant because you the perspective that is most relevant is niemeyer's, and my internal niemeyer sim is not an outstanding predictor of the real niemeyer's thought [09:01] fwereade: it seems to me that there are several levels of verification we have on the state [09:01] :-) [09:02] rog, I think I do have to step back and sketch everything out again :) [09:02] fwereade: i'm looking at niemeyer's paste, and it seems to me that his environs/config is trivial [09:02] fwereade: and not really worth it [09:03] fwereade: each of the different methods on config.Config just return a particular field of the map [09:04] rog, look, yes, I am somewhat sympathetic to that point of view; if the prevailing opinion is that the content of /environment is a free-for-all and we can handle that then map[string]interface{} is perfectly sufficient [09:05] rog, however at the moment I am somewhat without compass and it has become apparent that I need to chart the differences between my perspective and niemeyer's in some detail so I can actually proceed usefully [09:05] fwereade: i'm sympathetic to this point of view of niemeyer's: " [09:05] There are very [09:05] few places through which configuration get into the system, and the [09:05] configuration should be validated right there. [09:05] " [09:05] fwereade: so the content of /environment is only a free-for-all if we treat it as such [09:05] rog, my concern is that if we can then at some stage we will [09:06] fwereade: and placing the validation outside of state means that everything else becomes simpler. [09:06] fwereade: (the fewer places with registered global state the better, i think) [09:08] fwereade: the idea behind State isn't, i think, that we design it such that it can express *exactly* the things we can do in juju, but that it's a nice convenient abstraction layer that expresses *at least* the things we can do in juju. [09:09] fwereade: when we start making things more complex so that we can get more verification in State, i think we're going a little too far. [09:09] fwereade: it's a convenience for our own use, and i don't think we need to be bound by it. [09:09] rog, I just don't see how requiring explicit validation outside of Config objects *actually* makes things simpler [09:09] rog, it just means we need to do lets of external messing about with maps and typecasting [09:09] fwereade: it means we don't need a new package with separate global registration [09:10] rog, if that's the only objection then that can be worked around [09:11] fwereade: really? i thought that was inherent to the cyclic-dependency-breaking nature of environs/config. [09:11] rog, oh wait, maybe not [09:11] rog, no, it means we need a provider to get a config and there's no way around it [09:12] fwereade: yup [09:12] fwereade: i'm not sure where you think all the messing around with maps and typecasting will go [09:14] rog, my perspective just clicked around a notch [09:14] :-) [09:15] rog, I can restrict the messing around to only the bits that are directly concerned with the struct type [09:15] fwereade: not sure i understand [09:16] rog, ok, this perspectives STM to assume that ValidateConfig will directly construct struct types from its *Config (or map) params [09:16] rog, will manipulate those as required [09:16] rog, and then return a fully validated one [09:17] rog, as a new *Config (or map) [09:17] fwereade: i don't think there's any need to return a validated config. [09:17] fwereade: is there? [09:17] fwereade: isn't the "new" argument supposed to be valid? [09:17] rog, how are we meant to know that? [09:18] fwereade: isn't that what ValidateConfig checks? [09:18] rog, yeah, a valid user-specified config may still require manipulation [09:18] rog, (1) region must never change at runtime, so we should bake in the value in case an update changes the default region [09:19] fwereade: that's why we pass in the old config, no? [09:19] rog, (2) authorized-keys-path should not exist on the server -- if it does it's evidence of total crazkfulness on our part [09:19] rog, and we should therefore remove it and sub in a correct authorized-keys setting [09:20] fwereade: how does the provider know that it's on a server or not? [09:20] rog, right! it shouldn't have to -- it shouldn't even see anything that could indicate a difference [09:21] rog, the actual configuration setting is authorized-keys -- authorized-keys-path is a convenient alternate way of setting it [09:22] rog, the environment should not have to care even slightly about what filesystem it happens to be running on, or even I guess whether it is ;) [09:22] hmm [09:23] fwereade: i see. what we get out of environments.yaml isn't what we put into the state. [09:23] yuck [09:24] rog, yeah, I have this total conviction that they are two distinct things and we could make our lives easier by distinguishing them in code [09:24] rog, but that has not received a lot of traction [09:25] rog, to tweak what you said: what we get out of environments.yaml isn't what fwereade personally thinks we put into the state. [09:25] rog, I guess we could just have the field and not bother to look at it when it might not be valid, but that seems pretty crackful itself [09:25] to me [09:26] fwereade: mutating authorized-keys-path makes sense. [09:27] fwereade: this *was* my idea for how ValidateConfig would work: http://paste.ubuntu.com/1082463/ [09:27] rog, yeah, I think it needs a little more [09:28] fwereade: the problem with making client-side and server-side config two different things is that they are really very similar! [09:28] rog, sure [09:29] fwereade: hmm, against my previous inclination, perhaps we should just have Environ.Config to return a configuration map from an opened environ [09:30] rog, but if we had struct types we could just serialize/deserialize the struct types with yaml for storage, and *only* ever let valid struct types into the system, and only bother with the fancy stuff when loading a user config [09:30] rog, yeah, that feels to me like a sensible thing [09:32] fwereade: that means we'd need two versions of the deserializing code, which seems somewhat like overkill to me. [09:33] fwereade: also, we can't deserialize directly from a config code, i think. [09:33] s/code/node/ [09:33] rog, one which just blats the yaml direct into a struct, and one that contains all the pre-validation and tweaking etc? [09:33] rog, oh? why not? [09:34] rog, I would imagine we could just blat it straight into a *whateverConfig [09:34] fwereade: because yaml.Unmarshal takes a []byte [09:34] fwereade: not a map[string]interface{} [09:35] rog, yes, this also depends on the separate global config registry so that we can have the configs directly responsible for what is stored [09:35] rog, which I know you don;t like [09:36] fwereade: the *only* reason that i made config parsing separate from config opening was so that a config file would get validated completely. [09:36] fwereade: and actually, that's still possible with ValidateConfig [09:36] rog, I don't actually see the benefit of refusing to work with env X because env Y is broken [09:39] fwereade: you may well be right. in which case i'm very happy to live without passing around configurations as structs. [09:39] fwereade: i'm happy to have state never call into environs [09:39] rog, yeah, I know :) [09:40] fwereade: it seems like a reasonable separation of concerns to me [09:41] fwereade: BTW does state actually need to know anything that goes on inside the environ config at all? [09:42] fwereade: for instance, does the state need to know that environ name, default series or type? [09:42] rog, only if we care about its validity -- and I still think we do/should but I think I have been pretty comprehensivelyoverruled on that one [09:42] s/that/the/ [09:42] rog, certainly default-series [09:42] fwereade: of course we care about its validity... [09:42] rog, yes, but it has been argued that we can trust the clients [09:42] fwereade: they're our clients, so can we trust ourselves? [09:43] rog, and therefore at that specific point we merely assume validity, rather than worrying about it [09:43] fwereade: yea [09:43] h [09:43] fwereade: what does state use default-series for? [09:43] rog, IMO no, of course we can't trust ourselves ;p [09:43] rog, deploy command [09:43] rog, and the only sane place to get it is from state [09:43] fwereade: the deploy command isn't in state, is it? [09:44] rog, how is it going to get the default series *except* from state? [09:44] fwereade: i'm not suggesting that the default series isn't store inside state, [09:44] stored [09:45] fwereade: but that state has no reason to get default-series (or any environ config attribute) itself [09:45] fwereade: i.e. for the purposes of the state package, the environ config is opaque [09:45] rog, well there was talk of a state.DefaultSeries a while back but I think that would indeed want reevaluation in the light of the current direction [09:47] rog, it all comes down to how much we trust ourselves, and I have found that *not* trusting myself is frequently a winning strategy [09:48] rog, I am happy to follow the collective wisdom on this point but I have not successfully internalised the attitude that the decision follows from [09:48] fwereade: it's a trade-off as always IMHO. i've also found that keeping things as simple as possible is good. [09:49] fwereade: it's also a matter of how easy it is to verify the trust [09:49] fwereade: in this case, i think there are only a very few places that need verification. [09:51] rog, yeah, I know -- I'm just saying it's a tradeoff I would make differently, and that makes it harder because my complexity-predicting heuristics lead me in a different direction to that I am consciously aiming for [10:04] fwereade: here's a representation of my current thinking: http://paste.ubuntu.com/1082500/ [10:05] fwereade: oops, EnvironConfig should have gone there [10:05] rog, was wondering about that [10:06] rog, not implausible, I'm just trying to think through the consequences of a slightly different shape [10:44] davecheney: hiya! [10:53] what's the difference between Test and TestPackage in Gocheck? [10:57] s/in/for/ [11:11] rog: howdy mate [11:11] had a good holiday ? [11:11] davecheney: that i have [11:11] davecheney: just trying to get up to speed with all the stuff that's happened while i've been gone... [11:12] davecheney: how're the agents these days? [11:12] davecheney: did you manage to get that branch working? [11:16] Aram: i don't understand your question [11:17] rog: the function used to integrated gocheck tests into gotest sometimes is named Test, sometimes TestPackage. [11:17] any particular meaning to that? [11:18] Aram: it looks like Test is standard [11:19] Aram: but it doesn't matter too much [11:19] ok. [11:20] rog: yup, it's waiting on final approval now [11:20] davecheney: yay! [11:21] davecheney: so the machine agent is actually starting new machines now? [11:21] davecheney: i mean the PA of course [11:21] rog: no [11:21] sadly not [11:22] we're still stuck at the 'who pushes the secrets' problem [11:22] davecheney: ah, of course. [13:07] Gooood Mondays! [13:09] hey hey [13:14] niemeyer: yo! [13:18] rog: Welcome back! [13:19] niemeyer: i was discussing the newly proposed environs/config package with fwereade earlier [13:20] niemeyer: i think i'm broadly in agreement with your take on it [13:20] rog: That's great.. I think we're all in agreement then, phew [13:20] niemeyer: i'm not sure that the actual package pulls its weight though [13:21] rog: The package is needed for the state package to not have a dependency on environs [13:21] niemeyer: i was wondering about something like this: http://paste.ubuntu.com/1082729/ [13:21] niemeyer: i'm not sure [13:22] niemeyer: i think the main reason for the dependency was so that state could call back into environs to verify the config [13:22] niemeyer: but your proposal does away with that [13:22] niemeyer: and hence, i *think*, the need for a new package [13:22] rog: Yes, and state still wants to return a Config [13:22] rog: Despite the fact it won't be validating [13:22] niemeyer: it could just return a map[string]interface{} [13:23] rog: Yes, it could be less nice, but it can be nicer too [13:23] niemeyer: which can then be validated outside state [13:23] rog: There's no need to validate what's coming out of state [13:23] rog: It was validated when going in [13:23] niemeyer: oh yes, that's true [13:25] niemeyer: if we *do* have a config package, i also wondered if it was really worth hiding the map. [13:25] type Config map[string]interface{} [13:25] might be more transparent [13:25] rog: I think it is, because we don't want code to be fiddling with the map in principle [13:26] niemeyer: ok, fair enough [13:26] rog: Nor using stock methods (DefaultSeries) from the map [13:26] niemeyer: i don't mind m["default-series"].(string) too much [13:27] niemeyer: but i see your point too [13:28] rog: I do mind, because it's just as easy to write m["default-seres"].(string) [13:29] niemeyer: presumably we'd also need config.New(attrs map[string]interface{}) (*Config, error) too? [13:30] niemeyer: with a config package, i might suggest something like this: http://paste.ubuntu.com/1082741/ [13:30] rog: Yeah, that sounds good [13:31] rog: Yeah, that looks mostly ok.. the Validate method needs to return a new config, though, because the proposal is to have config being immutable for now [13:32] niemeyer: why does validate need to return a new config? [13:32] niemeyer: isn't the new config already valid? [13:32] rog: The transition from -keys-path to -keys will be done there [13:32] niemeyer: i thought that could be done by Environ.Config [13:33] rog: Doing SetConfig/Config so we can get a proper configuration is awkward.. validation sounds like the proper place to do it [13:34] niemeyer: it seems like Validate is doing more than just validation here. [13:35] Validate \Val"i*date\, v. t. [See {Valid}.] [13:35]