The future of Factory

[namit-chandwani]

As of now, this is how our Factory struct looks like:

type Factory struct {
	// Type which defines the streams for the CLI
	IOStreams *iostreams.IOStreams
	// Logger provides functions for unified logging
	Logger logging.Logger
	// Localizer localizes the text in commands
	Localizer localize.Localizer
	// CfgHandler provides the fields required for managing config
	CfgHandler *config.CfgHandler
}

• In the ideal scenario, Factory should be initialized in the host CLI and passed down to its plugins.
  However, in the current setup of host and plugin examples, the Factory is being initialized in the plugins themselves.

• The only thing blocking us from achieving what we want is the Localizer.
  Since each CLI's localizer configuration is unique, it doesn't make much sense to share it between host and their plugins.

• One way to fix this is by removing Localizer field from the Factory struct (as proposed by @wtrocki in charmil CLI for starter project #155 (comment))

Let's come up with some more ideas for this and then decide which one to move forward with.

---

CC @aerogear/charmil-core

Ref: #155 (comment), #155 (comment), #153

[wtrocki]

Localizer can be part of starter template

[namit-chandwani]

@jackdelahunt @ankithans What are your thoughts on this?
If you're fine with this approach, I can make a PR for it before the config one.

[wtrocki]

Lets work on config :)
i18n is already in starter so there is nothing to work on right now.

[namit-chandwani]

Yeah, I'm working on config right now.

Last time, I had to apply this workaround to avoid breaking any existing code.
So I was just trying to prevent it this time around (maybe by removing Localizer from the Factory struct).

But yes, this can be done later too

[wtrocki]

Remove i18n refactor what is needed and break stuff. No one is using core (yet)

[namit-chandwani]

Got it. Thanks!