generate: Move Generator.spec to Generator.Config

[wking]

This makes the attribute public, since quite a few config manipulations are easier using Go's types than they are via getter/setter/mutator methods. This also means that we can drop methods that are more awkward than direct access (although we'll want to keep methods that are more convenient than direct access). I haven't done any method-dropping in this commit though, aside from the getter/setter for the config itself. I'd called for this back when we started adding these methods, and @mrunalp was sounding more positive about the public-attribute approach a few weeks ago.

I've also renamed this from “spec” to “config”, because it is a config. I'm not sure why runtime-spec decided to call the main config.go type Spec, but I don't think we should repeat that idiosyncrasy. This breaks our current library API in a few places (e.g. NewFromSpec → NewFromConfig), but the migration shouldn't be that bad and I think it's worth it to make life easier for future consumers.

[Mashimiao]

In my opinion, I hope Generator could be a general library in the future. From our side, it can help us keep code of subcommand generate to be concise and other projects or tools may import our library to create container config.
This is my own opinion. We can listen to other people's opinions. @opencontainers/runtime-tools-maintainers

[wking]

I hope Generator could be a general library in the future.

I agree, and I think this change will help us provide a better API. To help evaluate the change, I'll work up a follow-up PR that builds on this to transition some internal consumers, and we can decide if the transitioned code is more or less concise.

Of course, there may be some benefit in buffering downstream users from runtime-caller Go type changes. I expect those to drop off as runtime-caller stabilizes, but "drop off" isn't "stop". Whether that isolation is worth the cost of writing and maintaining per-property wrappers is a maintainer call.

[wking]

On Mon, Nov 07, 2016 at 07:33:35PM -0800, W. Trevor King wrote:

To help evaluate the change, I'll work up a follow-up PR that builds
on this to transition some internal consumers, and we can decide if
the transitioned code is more or less concise.

Pushed with #267.

[liangchenye]

It is already a general library right? @Mashimiao
Changing 'spec' to 'config' makes sense.

[liangchenye]

Conflicts detected, other wise LGTM

[wking]

On Tue, Nov 22, 2016 at 03:33:33AM -0800, 梁辰晔 (Liang Chenye) wrote:

Conflicts detected, other wise LGTM

Rebased onto the current master with f633ad2 → 2a3cb43.

[Mashimiao]

There is an error, please refer to travis-ci log

[wking]

On Tue, Nov 22, 2016 at 05:12:11PM -0800, Ma Shimiao wrote:

There is an error, please refer to travis-ci
log

Oops, thanks. Fixed with 2a3cb43 → 6815c45.

[Mashimiao]

need another rebase

[wking]

On Tue, Nov 22, 2016 at 09:32:12PM -0800, Ma Shimiao wrote:

need another rebase

Rebased again with 6815c45 → a0fe802.

[Mashimiao]

LGTM

[Mashimiao]

@wking need another rebase

[wking]

On Mon, Feb 13, 2017 at 07:21:04PM -0800, Ma Shimiao wrote: @wking need another rebase

Rebased with a0fe802 → 986f514, although I did a lot of the update with ‘sed’, so I may have missed some. If this PR might actually collect two LGTMs before it needs another rebase, feel free to ping me and I'll go over 986f514 more carefully.

[Mashimiao]

LGTM

[zhouhao3]

Need rebase.

[wking]

Need rebase.

This one is a pain to rebase ;). It's milestoned 0.6.0 now, so it's probably better to just wait and rebaae after 0.5.0 is cut and we have a better chance of collecting two LGTMs before it goes stale again ;).

[zhouhao3]

@wking It's already 0.5, please update.

[wking]

This is going to conflict with #194, so I'll wait and rebase this one after that settles.

[wking]

With #194 landed, I've rebased this onto master with 986f514 → 84a62c6.

[zhouhao3]

LGTM