Add a flag --init to write a default config #81
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
benjaminjkraft
requested review from
aberkan,
dnerdy,
MiguelCastillo and
StevenACoffman
dnerdy
approved these changes
Sep 9, 2021
Comment on lines
+136
to
+127
| // Parse the config that `genqlient --init` generates, to make sure that | ||
| // works. |
generate/main.go
Outdated
| @@ -36,25 +38,32 @@ func readConfigGenerateAndWrite(configFilename string) error { | |||
| return nil | |||
| } | |||
|
|
|||
| type cliArgs struct { | |||
| ConfigFilename string `arg:"positional" placeholder:"FILENAME" default:"genqlient.yaml" help:"path to genqlient configuration (default genqlient.yaml)"` | |||
There was a problem hiding this comment.
Perhaps placeholder:"CONFIG"?
Steve pointed out (#73) that having genqlient with no arguments silently use a default config file was a bit confusing, and changed it to use `genqlient.yaml` by default (#74). Mark pointed out (#76) that this makes it a bit less convenient when you're starting from scratch; you have to go create a config file. In this commit I add a new init flag that creates you a config file before using it. Originally the suggestion was to use subcommands, e.g. we'd have `genqlient init` and `genqlient generate` and so on. But I couldn't think of anything else we might want subcommands for in the future, and it felt a little silly to make you type `generate` each time. So instead, I made it a flag, which has the nice property that you can do `genqlient --init` and it will generate and then use a config file. (I mean, maybe it will immediately crash because you don't have a schema, but hopefully that's still a useful clue as to what to do next!) The implmentation was fairly trivial. Since we now have a nice way to generate a default config, I removed the default values for most of the options; I've always felt they were probably more confusing than helpful. (And indeed, all the users I know of (Khan/webapp, and the much smaller project Steve was working on, are setting those options explicitly.) I decided this is also a good time to pull in a proper CLI parser (#31); see ADR-504 for more on that choice. This also adds some nice help messages! Fixes #76, #31. Issue: #76 Test plan: ``` go run . go run . --init go run . --init example/genqlient.yaml ``` Reviewers: marksandstrom, steve, adam, miguel
benjaminjkraft
force-pushed
the
benkraft.init
branch
from
acd5c80 to
9de1cf4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Steve pointed out (#73) that having genqlient with no arguments silently
use a default config file was a bit confusing, and changed it to use
genqlient.yamlby default (#74). Mark pointed out (#76) that thismakes it a bit less convenient when you're starting from scratch; you
have to go create a config file. In this commit I add a new init flag
that creates you a config file before using it.
Originally the suggestion was to use subcommands, e.g. we'd have
genqlient initandgenqlient generateand so on. But I couldn'tthink of anything else we might want subcommands for in the future, and
it felt a little silly to make you type
generateeach time. Soinstead, I made it a flag, which has the nice property that you can do
genqlient --initand it will generate and then use a config file. (Imean, maybe it will immediately crash because you don't have a schema,
but hopefully that's still a useful clue as to what to do next!) The
implmentation was fairly trivial.
Since we now have a nice way to generate a default config, I removed the
default values for most of the options; I've always felt they were
probably more confusing than helpful. (And indeed, all the users I know
of (Khan/webapp, and the much smaller project Steve was working on, are
setting those options explicitly.) This required a slight change to
the syntax to say "don't use context", which is probably also net clearer.
I decided this is also a good time to pull in a proper CLI parser (#31);
see ADR-504 for more on that choice. This also adds some nice help
messages!
Fixes #76, #31.
Issue: #76
Test plan: