-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add subcommands to init config file, and otherwise require the config file exists #76
Comments
benjaminjkraft
added a commit
that referenced
this issue
Sep 8, 2021
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
added a commit
that referenced
this issue
Sep 10, 2021
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
added a commit
that referenced
this issue
Sep 10, 2021
## 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.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.) 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: ``` go run . go run . --init go run . --init example/genqlient.yaml # refuses to clobber go run . --init example/newgenqlient.yaml ``` Author: benjaminjkraft Reviewers: dnerdy, aberkan, MiguelCastillo, StevenACoffman Required Reviewers: Approved By: dnerdy Checks: ✅ Test (1.17), ✅ Test (1.16), ✅ Test (1.15), ✅ Test (1.14), ✅ Lint, ✅ Test (1.17), ✅ Test (1.16), ✅ Test (1.15), ✅ Test (1.14), ✅ Lint Pull Request URL: #81
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follow-up to #73 : Require the file to exist but make it easy to create an initial config? We could do this by introducing subcommands, e.g.:
That would make it easy for users to get up and running (and the default config could provide pointers into the documentation) while also avoiding any potential confusion.
The text was updated successfully, but these errors were encountered: