96dccca475
This enables imports in mcl code, and is one of last remaining blockers to using mgmt. Now we can start writing standalone modules, and adding standard library functions as needed. There's still lots to do, but this was a big missing piece. It was much harder to get right than I had expected, but I think it's solid! This unfortunately large commit is the result of some wild hacking I've been doing for the past little while. It's the result of a rebase that broke many "wip" commits that tracked my private progress, into something that's not gratuitously messy for our git logs. Since this was a learning and discovery process for me, I've "erased" the confusing git history that wouldn't have helped. I'm happy to discuss the dead-ends, and a small portion of that code was even left in for possible future use. This patch includes: * A change to the cli interface: You now specify the front-end explicitly, instead of leaving it up to the front-end to decide when to "activate". For example, instead of: mgmt run --lang code.mcl we now do: mgmt run lang --lang code.mcl We might rename the --lang flag in the future to avoid the awkward word repetition. Suggestions welcome, but I'm considering "input". One side-effect of this change, is that flags which are "engine" specific now must be specified with "run" before the front-end name. Eg: mgmt run --tmp-prefix lang --lang code.mcl instead of putting --tmp-prefix at the end. We also changed the GAPI slightly, but I've patched all code that used it. This also makes things consistent with the "deploy" command. * The deploys are more robust and let you deploy after a run This has been vastly improved and let's mgmt really run as a smart engine that can handle different workloads. If you don't want to deploy when you've started with `run` or if one comes in, you can use the --no-watch-deploy option to block new deploys. * The import statement exists and works! We now have a working `import` statement. Read the docs, and try it out. I think it's quite elegant how it fits in with `SetScope`. Have a look. As a result, we now have some built-in functions available in modules. This also adds the metadata.yaml entry-point for all modules. Have a look at the examples or the tests. The bulk of the patch is to support this. * Improved lang input parsing code: I re-wrote the parsing that determined what ran when we passed different things to --lang. Deciding between running an mcl file or raw code is now handled in a more intelligent, and re-usable way. See the inputs.go file if you want to have a look. One casualty is that you can't stream code from stdin *directly* to the front-end, it's encapsulated into a deploy first. You can still use stdin though! I doubt anyone will notice this change. * The scope was extended to include functions and classes: Go forth and import lovely code. All these exist in scopes now, and can be re-used! * Function calls actually use the scope now. Glad I got this sorted out. * There is import cycle detection for modules! Yes, this is another dag. I think that's #4. I guess they're useful. * A ton of tests and new test infra was added! This should make it much easier to add new tests that run mcl code. Have a look at TestAstFunc1 to see how to add more of these. As usual, I'll try to keep these commits smaller in the future!
92 lines
4.2 KiB
Go
92 lines
4.2 KiB
Go
// Mgmt
|
|
// Copyright (C) 2013-2018+ James Shubin and the project contributors
|
|
// Written by James Shubin <james@shubin.ca> and the project contributors
|
|
//
|
|
// This program is free software: you can redistribute it and/or modify
|
|
// it under the terms of the GNU General Public License as published by
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
// (at your option) any later version.
|
|
//
|
|
// This program is distributed in the hope that it will be useful,
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
// GNU General Public License for more details.
|
|
//
|
|
// You should have received a copy of the GNU General Public License
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
package interfaces
|
|
|
|
import (
|
|
"github.com/purpleidea/mgmt/engine"
|
|
"github.com/purpleidea/mgmt/lang/types"
|
|
)
|
|
|
|
// Info is a static representation of some information about the function. It is
|
|
// used for static analysis and type checking. If you break this contract, you
|
|
// might cause a panic.
|
|
type Info struct {
|
|
Pure bool // is the function pure? (can it be memoized?)
|
|
Memo bool // should the function be memoized? (false if too much output)
|
|
Sig *types.Type // the signature of the function, must be KindFunc
|
|
Err error // is this a valid function, or was it created improperly?
|
|
}
|
|
|
|
// Init is the structure of values and references which is passed into all
|
|
// functions on initialization.
|
|
type Init struct {
|
|
Hostname string // uuid for the host
|
|
//Noop bool
|
|
Input chan types.Value // Engine will close `input` chan
|
|
Output chan types.Value // Stream must close `output` chan
|
|
// TODO: should we pass in a *Scope here for functions like template() ?
|
|
World engine.World
|
|
Debug bool
|
|
Logf func(format string, v ...interface{})
|
|
}
|
|
|
|
// Func is the interface that any valid func must fulfill. It is very simple,
|
|
// but still event driven. Funcs should attempt to only send values when they
|
|
// have changed.
|
|
// TODO: should we support a static version of this interface for funcs that
|
|
// never change to avoid the overhead of the goroutine and channel listener?
|
|
type Func interface {
|
|
Validate() error // FIXME: this is only needed for PolyFunc. Get it moved and used!
|
|
Info() *Info
|
|
Init(*Init) error
|
|
Stream() error
|
|
Close() error
|
|
}
|
|
|
|
// PolyFunc is an interface for functions which are statically polymorphic. In
|
|
// other words, they are functions which before compile time are polymorphic,
|
|
// but after a successful compilation have a fixed static signature. This makes
|
|
// implementing what would appear to be generic or polymorphic instead something
|
|
// that is actually static and that still has the language safety properties.
|
|
type PolyFunc interface {
|
|
Func // implement everything in Func but add the additional requirements
|
|
|
|
// Polymorphisms returns a list of possible function type signatures. It
|
|
// takes as input a list of partial "hints" as to limit the number of
|
|
// possible results it returns. These partial hints take the form of a
|
|
// function type signature (with as many types in it specified and the
|
|
// rest set to nil) and any known static values for the input args. If
|
|
// the partial type is not nil, then the Ord parameter must be of the
|
|
// correct arg length. If any types are specified, then the array must
|
|
// be of that length as well, with the known ones filled in. Some
|
|
// static polymorphic functions require a minimal amount of hinting or
|
|
// they will be unable to return any possible result that is not
|
|
// infinite in length. If you expect to need to return an infinite (or
|
|
// very large) amount of results, then you should return an error
|
|
// instead. The arg names in your returned func type signatures should
|
|
// be in the standardized "a..b..c" format. Use util.NumToAlpha if you
|
|
// want to convert easily.
|
|
Polymorphisms(*types.Type, []types.Value) ([]*types.Type, error)
|
|
|
|
// Build takes the known type signature for this function and finalizes
|
|
// this structure so that it is now determined, and ready to function as
|
|
// a normal function would. (The normal methods in the Func interface
|
|
// are all that should be needed or used after this point.)
|
|
Build(*types.Type) error // then, you can get argNames from Info()
|
|
}
|