Add a script for automatically updating scheme

[wzshiming]

Currently manually maintained dependencies may be lost, so a new script has been added to keep them in sync

xref #3

[siyuanfoundation]

This is awesome! Thank you @wzshiming for working on this!

[wzshiming]

This is not used in the current project and has been removed in the latest k8s version, maybe we should remove it?

[siyuanfoundation]

yes, let's remove it.

[wzshiming]

Should we somehow support api's that have been removed?

#10

[siyuanfoundation]

I think it is fine to not support apis that have been removed. But we should

• Build and publish releases for all recent kubernetes versions (1.6+)
• Can you add instructions about how to build the tool for an specific version of k8s in README using the script? It can be a follow up PR.

[wzshiming]

Build and publish releases for all recent kubernetes versions (1.6+)

I think it would be possible to use a script to copy the deleted apiversion to the current repository, similar to what this PR currently does. #10

WDYT?

Can you add instructions about how to build the tool for an specific version of k8s in README using the script? It can be a follow up PR.

Of course, I've moved the initialisation of scheme to main, which allows different versions to co-exist, and I'll try to improve the documentation later.

[siyuanfoundation]

while it would be possible to use a script to copy the deleted apiversion to the current repository, we still need to make decisions about how far back we want to support. We can start a discussion in the other issue.

[wzshiming]

Done

[siyuanfoundation]

why is this needed?

[wzshiming]

Sorry I mistook it for a comment on a Makefile change

By default, Makefile targets are "file targets" - they are used to build files from other files. Make assumes its target is a file, and this makes writing Makefiles relatively easy:

foo: bar
  create_one_from_the_other foo bar

However, sometimes you want your Makefile to run commands that do not represent physical files in the file system. Good examples for this are the common targets "clean" and "test". Chances are this isn't the case, but you may potentially have a file named clean in your main directory. In such a case Make will be confused because by default the clean target would be associated with this file and Make will only run it when the file doesn't appear to be up-to-date with regards to its dependencies.

These special targets are called phony and you can explicitly tell Make they're not associated with files, e.g.:

.PHONY: clean
clean:
  rm -rf *.o

Now make clean will run as expected even if you do have a file named clean.

In terms of Make, a phony target is simply a target that is always out-of-date, so whenever you ask make <phony_target>, it will run, independent from the state of the file system.

See also: GNU make manual: Phony Targets

[wzshiming]

I moved the registration of scheme to a separate package pkg/scheme, if I hadn't introduced it then scheme wouldn't have existed in this test and it wouldn't have passed the test.

[siyuanfoundation]

you can move

func init() {
	AddToScheme(scheme.Scheme)
}

to pkg/encoding/encoding.go, and the init file would not be needed.

[wzshiming]

There is a reason for this.

Imagine a scenario where I introduce this package in another project, but due to the differences in apiversion of the different versions of k8s used this package cannot be used, because some paths may not exist.

If I do this, the other project can take care of registering the scheme itself.

[wzshiming]

I filed an issue #10 that I planned to implement by writing a script to copy the deleted scheme to "github.com/etcd-io/auger/pkg/old_scheme"

If the caller doesn't care about the k8s version, they can just use

import (
	_ "github.com/etcd-io/auger/pkg/scheme"
	_ "github.com/etcd-io/auger/pkg/old_scheme"
)

otherwise regenerate scheme in their own repo using the two scripts we provided

import (
	_ "path/to/pkg/scheme"
	_ "path/to/pkg/old_scheme"
)

[siyuanfoundation]

In that case, should the schemes be passed in as arguments toAddToScheme?
When doing

import (
	_ "path/to/pkg/scheme"
	_ "path/to/pkg/old_scheme"
)

you need to consider duplicates and conflicts.

[siyuanfoundation]

you can move

func init() {
	AddToScheme(scheme.Scheme)
}

to pkg/encoding/encoding.go, and the init file would not be needed.

[siyuanfoundation]

please add init() function in the encoding.go instead of a new init file. init files are more like a python pattern instead of go.

[wzshiming]

I am planning to refactor encoding.go to pass these global variables as arguments, at which point the file will be removed.

The core goal is to be able to import this package directly from other projects.

[siyuanfoundation]

I like the idea of passing arguments. To import this package directly into other projects, I think that can be better achieved by adding functions like UpdateScheme and MergeSchemes if multiple schemes were to be used.
Or like you said, refactor the code to have Codecs passed in everywhere instead of having a global variable.

The init files everywhere as this PR goes, are not necessary and looks weird.

[wzshiming]

This PR requires a member to approve the execution of the workflow

/cc @siyuanfoundation
/cc @jmhbnz
/cc @wenjiaswe

[jmhbnz]

/ok-to-test

[wzshiming]

Sorry for the late reply, I refactored the logic as discussed, please take a look again.

[siyuanfoundation]

/approve

@jmhbnz for double check

[jmhbnz]

This is a great first iteration, thanks @wzshiming

Can you please rebase following #34 which fixed some lint errors so we can merge.

[wzshiming]

Done.