export environ as its own lib #169
Conversation
nickatsegment
requested review from
eculver,
dfuentes,
systemizer,
boggsboggs and
Fauzyy
| // LoadNoPaths is identical to Load, but uses v1-style "."-separated paths | ||
| // | ||
| // Deprecated like all noPaths functionality | ||
| func (e *Environ) LoadNoPaths(s store.Store, service string, collisions *[]string) error { |
There was a problem hiding this comment.
This split is a little non-intuitive. Eventually we'll remove the NoPaths logic, and I'd like to keep the Load function. At that point we can roll key and load into Load.
There was a problem hiding this comment.
if we're using environ functionality across multiple CLI's, it might make sense eventually to break it out into it's own repo. Just want to prevent the case where a future engineer adds to the environ library for chamber specific use-cases but forgets there are other tools using it.
Not a big deal now that since we're not actively iterating on chamber.
|
@systemizer Yes, that's a possibility. My stance is that as soon as you export a symbol, you should assume it's widely used and should endeavour to not break contract. |
|
Realizing that I should have made Load() accept a new interface that only requires ListRaw, since that's all it really needs. Would make mocking simpler. |
I could have just copy-pasted this stuff, but there's a fair amount of fiddly details that I think could use capturing in their own exported library
This is for another docker entrypoint system that I'm working on that would work better if chamber weren't an extra binary.