2017-06-26 23:46:34 +02:00
|
|
|
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
|
2017-04-12 20:04:04 +02:00
|
|
|
|
|
|
|
package main
|
|
|
|
|
|
|
|
import (
|
|
|
|
"github.com/golang/glog"
|
|
|
|
"github.com/spf13/cobra"
|
2017-04-13 14:27:45 +02:00
|
|
|
|
2017-06-02 21:43:04 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/compiler"
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/compiler/binder"
|
2017-06-02 21:43:04 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/compiler/core"
|
|
|
|
"github.com/pulumi/lumi/pkg/compiler/errors"
|
|
|
|
"github.com/pulumi/lumi/pkg/compiler/symbols"
|
|
|
|
"github.com/pulumi/lumi/pkg/pack"
|
2017-05-18 20:38:28 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/util/cmdutil"
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/util/contract"
|
2017-04-12 20:04:04 +02:00
|
|
|
)
|
|
|
|
|
2017-06-07 19:52:03 +02:00
|
|
|
// NewLumiCmd creates a new Lumi Cmd instance.
|
2017-05-18 20:38:28 +02:00
|
|
|
func NewLumiCmd() *cobra.Command {
|
2017-05-31 18:14:49 +02:00
|
|
|
var logFlow bool
|
2017-04-12 20:04:04 +02:00
|
|
|
var logToStderr bool
|
|
|
|
var verbose int
|
|
|
|
cmd := &cobra.Command{
|
2017-05-18 20:38:28 +02:00
|
|
|
Use: "lumi",
|
|
|
|
Short: "Lumi is a framework and toolset for reusable stacks of services",
|
2017-04-12 20:04:04 +02:00
|
|
|
PersistentPreRun: func(cmd *cobra.Command, args []string) {
|
2017-05-31 18:14:49 +02:00
|
|
|
cmdutil.InitLogging(logToStderr, verbose, logFlow)
|
2017-04-12 20:04:04 +02:00
|
|
|
},
|
|
|
|
PersistentPostRun: func(cmd *cobra.Command, args []string) {
|
|
|
|
glog.Flush()
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
2017-05-31 18:14:49 +02:00
|
|
|
cmd.PersistentFlags().BoolVar(&logFlow, "logflow", false, "Flow log settings to child processes (like plugins)")
|
2017-04-12 20:04:04 +02:00
|
|
|
cmd.PersistentFlags().BoolVar(&logToStderr, "logtostderr", false, "Log to stderr instead of to files")
|
|
|
|
cmd.PersistentFlags().IntVarP(
|
|
|
|
&verbose, "verbose", "v", 0, "Enable verbose logging (e.g., v=3); anything >3 is very verbose")
|
|
|
|
|
|
|
|
cmd.AddCommand(newConfigCmd())
|
|
|
|
cmd.AddCommand(newDeployCmd())
|
|
|
|
cmd.AddCommand(newDestroyCmd())
|
|
|
|
cmd.AddCommand(newEnvCmd())
|
|
|
|
cmd.AddCommand(newPackCmd())
|
|
|
|
cmd.AddCommand(newPlanCmd())
|
|
|
|
cmd.AddCommand(newVersionCmd())
|
|
|
|
|
|
|
|
return cmd
|
|
|
|
}
|
2017-06-02 21:43:04 +02:00
|
|
|
|
|
|
|
func prepareCompiler(cmd *cobra.Command, args []string) (compiler.Compiler, *pack.Package) {
|
2017-06-11 02:03:58 +02:00
|
|
|
// TODO[pulumi/lumi#88]: enable arguments to flow to the package itself. In that case, we want to split the
|
|
|
|
// arguments at the --, if any, so we can still pass arguments to the compiler itself in these cases.
|
|
|
|
var pkgarg string
|
|
|
|
if len(args) > 0 {
|
|
|
|
pkgarg = args[0]
|
2017-06-02 21:43:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Create a compiler options object and map any flags and arguments to settings on it.
|
|
|
|
opts := core.DefaultOptions()
|
|
|
|
|
|
|
|
// If a package argument is present, try to load that package (either via stdin or a path).
|
|
|
|
var pkg *pack.Package
|
|
|
|
var root string
|
2017-06-11 02:03:58 +02:00
|
|
|
if pkgarg != "" {
|
|
|
|
pkg, root = readPackageFromArg(pkgarg)
|
2017-06-02 21:43:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Now create a compiler object based on whether we loaded a package or just have a root to deal with.
|
|
|
|
var comp compiler.Compiler
|
|
|
|
var err error
|
|
|
|
if root == "" {
|
|
|
|
comp, err = compiler.Newwd(opts)
|
|
|
|
} else {
|
|
|
|
comp, err = compiler.New(root, opts)
|
|
|
|
}
|
|
|
|
if err != nil {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
cmdutil.Diag().Errorf(errors.ErrorCantCreateCompiler, err)
|
2017-06-02 21:43:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return comp, pkg
|
|
|
|
}
|
|
|
|
|
|
|
|
// compile just uses the standard logic to parse arguments, options, and to locate/compile a package. It returns the
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
// compilation result, or nil if an error occurred (in which case, we would expect diagnostics to have been output).
|
|
|
|
func compile(cmd *cobra.Command, args []string) *compileResult {
|
2017-06-02 21:43:04 +02:00
|
|
|
// Prepare the compiler info and, provided it succeeds, perform the compilation.
|
|
|
|
if comp, pkg := prepareCompiler(cmd, args); comp != nil {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
var b binder.Binder
|
2017-06-02 21:43:04 +02:00
|
|
|
var pkgsym *symbols.Package
|
|
|
|
if pkg == nil {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
b, pkgsym = comp.Compile()
|
2017-06-02 21:43:04 +02:00
|
|
|
} else {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
b, pkgsym = comp.CompilePackage(pkg)
|
2017-06-02 21:43:04 +02:00
|
|
|
}
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
contract.Assert(b != nil)
|
|
|
|
contract.Assert(pkgsym != nil)
|
2017-06-02 21:43:04 +02:00
|
|
|
return &compileResult{
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
C: comp,
|
|
|
|
B: b,
|
|
|
|
Pkg: pkgsym,
|
2017-06-02 21:43:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
type compileResult struct {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
C compiler.Compiler
|
|
|
|
B binder.Binder
|
|
|
|
Pkg *symbols.Package
|
2017-06-02 21:43:04 +02:00
|
|
|
}
|