daedaleanai / dbt Goto Github PK

dbt doesn't seem to work with go1.16 because what looks like module issues. Perhaps GO111MODULE=off needs explicitly setting when calling go from dbt?

$ go version
go version go1.16 linux/amd64

$ dbt build SomeTarget
go: [email protected] (replaced by github.com/daedaleanai/[email protected]): missing go.sum entry; to add it:
	go mod download dbt
Error: Failed to run generator in mode 'targets': exit status 1.
A fatal error occured. Exiting...

the generator should open the ninja file as file and not use the standard output

To be decided: Should "builtin" rules be imported via their full URL or should we keep the "replace" directive in mod.go files?

• descriptions for targets
• descriptions for flags
• default values for flags

The buildsOne / buildsMany interfaces should not have to return an OutPath. It's confusing. Let's use a different interface for that.

Store the hash with all dependencies and use that to check out the correct version. The tag / branch name should then be checked to match the hash.

• make rules coherent (e.g., CC-cross-compilation rules and Xilinx rules)
• move rules to an external package
• allow rules in different places than the RULES directory?

They are currently returned from the Build method. Maybe there should be another interface with a Outputs method to specify outputs?

Maybe by adding a Testable or Runnable interface

Q: What should the Outputs implementation of such a rule look like? The aggregated Output()s of all child steps?

Ninja can already generate dependency graphs. It's probably easiest to forward graph requests to Ninja and let Ninja do the heavy listing.

This way builds can be conserved and be re-executed in 30 years, when Ninja, Go etc. may be incompatible.

• add destripbions
• add auto-completable values

It would be helpful if there was a command which printed out the version of the tool. Then when you update, you can easily check you're running the new version.

eg something like this:
$ dbt version
dbt version dbt0.0.2

... maybe through another interface?
Descriptions of targets should be shown in the auto-complete