-
Notifications
You must be signed in to change notification settings - Fork 76
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
todo --configure #129
Comments
I'd like to postpone creating more config wizards until there's proper support from vdirsyncer to discover configured calendars. Khal probes the non-public API of vdirsyncer for this, which is nasty. |
Actually, my intention was for users to provide the exact value that ends up in the config file, not do some super-smart discovery. |
I see, I suppose that doesn't have to be postponed. |
Hello, I am new and would like to work on this one! According to what I interpret, changes ought to be made here in a manner such that when the configuration file is missing, instead of raising a Also, is it justified if we ask user to run this command as superuser if in case there were permission problems while writing the file? (For ex: I didin't define Thanks in advance! |
Hello @zebak12, glad to hear that!
Instead of directly launching the configuration wizard if no config exists, I would prefer it if we create a new command in
I don't think it's justified. |
To compliment a bit what @untitaker said:
Regarding your
The first of these two is the one you should use (the second will be read if none is present, but is system-wide instead of user-wide, and not recommended). |
Oh! Just got that 🎉 |
Great! Let me know if you have further questions moving forward. |
Hi, I have thought of some decorators for the configure function: @click.command()
@click.option("--location",
help='Stores where configuration file is present')
@click.option("--show",
help="Choose whether to show date/time both or date only")
@click.option("--path",
help="It contains where all your calendar files are presenet")
@click.option("--date_format",
help="The date format used both for displaying dates, and "
"parsing input dates. If this option is not specified "
"the ISO-8601 (%Y-%m-%d) format is used.")
@click.option("--color",
help="By default todoman disables colored output if stdout is"
" not a TTY (value auto). Set to never to disable colored"
" output entirely, or always to enable it regardless. This"
" can be overridden with the --color option.")
@click.option("--default_list",
help="The default list for adding a todo."
"If you do not specify this option, you must use "
"the --list / -l option every time you add a todo.")
@click.option("--default_due",
help="The default difference (in hours) between new todo’s "
"due date and creation date. If not specified, the "
"value is 24."
"If set to 0, the due date for new todos will not be set.")
@click.pass_context
def configure(ctx, location, path, show, date_format, color, default_list, default_due):
# Do something here
pass Am I on the right track (Isn't it too large) ? Thank You |
I'd rather have interactive questions (instead of cli flags) for configure.
etc. I think this is a it quite unlike the rest of what we have implemented already and more wizard-like. |
Oh! Thanks! Yeah! That would be much more intuitive. |
BTW, prompting can be done with http://click.pocoo.org/6/prompts/#input-prompts |
Why was this closed? I just installed todoman and a function like that would be very useful indeed. |
It hasn't been closed -- it's just that nobody's picked this up or had time to work on it so far. |
Ahh sorry, thought this issue was closed with #300 |
Hi I have written a config wizard for my CLI tool which prompts the user for parameters one at a time using a click wrapper. The CLI tool uses toml as the configuration format and the wizard relies on that, but it could be rewritten to work with ini so as not to add any dependencies to todoman. Would the todoman maintainers have time to review such PR? |
Yup, PRs for this are welcome. |
@WhyNotHugo, would it be more preferable if I separated the wizard into a separate module or fully merged the code into todoman? The wizard code is already fully covered by tests, and I utilize that code in my project. So the second approach would result in less new code in todoman. |
I think integrating it into a new module inside todoman makes sense the most. Can you share what you already have? Maybe seeing the existing code can help get a clearer vision of what would work best. |
Sure. Some background: Confluence poster is a tool to post Confluence pages that are written on the local system through a text editor. Config-wise the poster may have a global config in XDG_CONFIG_HOME and config in the working directory. There could be multiple pages in one directory posted to multiple places, so the config wizard allows generating additional sections for pages. The page logic is handled by functions with 'page' in the name, so those would be irrelevant to todoman. Confluence poster also allows storing password in the config (which is not recommended, but still is an option), so there is additional logic to handle hidden parameters. The way I implemented the wizard is I declare an iterable of DialogParameter objects or strings which are prompted in a row, optionally with default values fed from the existing config. This is the bag of helper functions, and this is the function that provides interactive wizard. Typer is a wrapper around click mostly focused on using parameters for command options instead of decorators, so rewriting the internals to click would be pretty fast. Sample run:
|
If there's no configuration file, offer to help create one:
Save show the configuration file, and confirm save/not save.
The text was updated successfully, but these errors were encountered: