making verdi setup & verdi quicksetup more user friendly #606
Conversation
So far, the procedure for choosing a custom profile name
in verdi quicksetup was a bit complicated:
it first checked whether a profile 'quicksetup' was already present
(which already requires sudo access);
if it existed, the user was asked whether to overwrite the profile
or not. by selecting no the user could then choose a new profile name.
This commit adds a prompt for the profile name in verdi quicksetup.
It is the very first prompt and it already has a default value
(i.e. one can simply press "enter" and doesn't lose time).
This is important in particular for setting up test profiles,
as those need to start with 'test_'.
The default name for the database was changed from
"aiida_qs_<login-name>" to
"<profile>_<login-name>"
This ensures that for test profiles the database name also starts with
'test_'.
and reverted default database user name back to aiida_qs_<login-name>
|
Ok, I've now realised that So, would it make sense to remove this default value or is it needed for something? Also, it seems the prompts for the user-properties in |
|
I think the default email can be removed everywhere. I agree that the UI should be consistent, indeed @DropD is in the process of converting everything to click (it's in one of the repositories under his account on GitHub) but this requires some time. Anyone is very welcome to help in the conversion process! |
|
And one more question: |
in addition to showing the doc strings of the functions, verdi help now shows the dynamically generated documentation of the 'click' options for verdi quicksetup and verdi setup. Adding this to other commands is achieved simply by adding a static '_ctx' method that returns the appropriate context.
|
I've added an easy way to have the There is a further quirk I ran into: Currently,
So, in my opinion
Do you agree? |
|
Hi Leo! Regarding the comment:
Maybe Quicksetup should just contain the logic for creating the DB, and then it would call the normal setup with the proper options (depending on what it created?) |
|
@DropD I am happy to help with the integration of your work into the aiida develop branch. |
when specified, quicksetup will *not* ask whether to override default profiles for shell/daemon
Finally a way to delete verdi profiles. Asks user whether to delete database & database user
|
Ok, so as discussed I have added a click option for quicksetup to avoid the prompt for making the new profile default in shell/daemon. I have added one more thing that I have been missing, which is "verdi profile delete myprofile". |
|
I just realised I forgot to delete the file repository. Also perhaps some of the functions I am using here (in particular the functions to manipulate the database) should probably not be inside quicksetup but rather in aiida.common.setup (?) |
Example of command line usage: $ verdi profile list * default * test_mynewtest * test_aiida * my_test > tdevelop (DEFAULT) (DAEMON PROFILE) (aiida_ltal) leopold@tsf-428-wpa-7-059:~/.aiida $ verdi profile delete test_aiida Delete associated database 'test_aiida'? WARNING: All data will be lost. [y/N]: y Deleting database 'test_aiida'. Delete database user 'test_aiida'? WARNING: This user might be used by other profiles as well. [y/N]: y Deleting user 'test_aiida'. Delete associated file repository '/Users/leopold/.aiida/repository-test_aiida/'? WARNING: All data will be lost. [y/N]: y Deleting directory '/Users/leopold/.aiida/repository-test_aiida/'. Delete configuration for profile 'test_aiida'? WARNING: This permanently removes the profile from the list of AiiDA profiles. [y/N]: y Deleting configuration for profile 'test_aiida'.
|
Finished a first implementation of verdi profile delete. |
verdi profile delete now checks whether the database of the profile actually exists and whether the database user is used by any other existing profiles. further adjustments to coding style following Sebastiaans suggestions.
aiida/cmdline/commands/profile.py
Outdated
| import os.path | ||
| from urlparse import urlparse | ||
|
|
||
| #TODO: the functions used below should be moved outside Quicksetup |
There was a problem hiding this comment.
Can you please make this into an issue instead of a TODO comment? You can assign it to me if you don't want to do it.
There was a problem hiding this comment.
Please also include in the issue that there are no tests for these functions as of yet.
aiida/cmdline/commands/profile.py
Outdated
| try: | ||
| profile = profiles[profile_to_delete] | ||
| except KeyError: | ||
| raise ValueError('Profile "{}" does not exist'.format(profile_to_delete)) |
There was a problem hiding this comment.
It might be more user friendly to either:
- check for inexistent profiles before starting to delete (and abort)
- give user an option to skip inexistent profiles (either cli or interactively or both)
- simply treat deleting a nonexistent profile as a noop (and maybe issue a warning)
There was a problem hiding this comment.
right, I'm going for the 3rd option
aiida/cmdline/commands/profile.py
Outdated
| db = profile.get('AIIDADB_NAME', '') | ||
| if not q._db_exists(db, pg_execute, **dbinfo): | ||
| print("Associated database '{}' does not exist.".format(db)) | ||
| elif click.confirm("Delete associated database '{}'?\n" \ |
There was a problem hiding this comment.
For usage with scripts (for example to automatically reset a testing environment), it would be helpful to have a non-interactive way to confirm deleting everything, say a --force option.
There was a problem hiding this comment.
Completely agree, I am going with '--yes' (in analogy with apt-get).
For the moment, I check by hand whether '--yes' is in the argument list as this is the way it is done with '--color' in another function in the same file.
To be replaced by more robust code in the future.
aiida/cmdline/commands/profile.py
Outdated
| elif users.count(user) > 1: | ||
| print("Associated database user '{}' is used by other profiles "\ | ||
| "and will not be deleted.".format(user)) | ||
| elif click.confirm("Delete database user '{}'?".format(user)): |
There was a problem hiding this comment.
Same consideration as above (--force) applies
aiida/cmdline/commands/profile.py
Outdated
| elif not os.path.isdir(repo_path): | ||
| print("Associated file repository '{}' is not a directory."\ | ||
| .format(repo_path)) | ||
| elif click.confirm("Delete associated file repository '{}'?\n" \ |
aiida/cmdline/commands/profile.py
Outdated
| "WARNING: All data will be lost.".format(repo_path)): | ||
| print("Deleting directory '{}'.".format(repo_path)) | ||
| import shutil | ||
| shutil.rmtree(repo_path) |
There was a problem hiding this comment.
Maybe it would make sense to already delegate the task of deleting to another function in a more obvious place which will do case handling for file system vs. object store / other future options - repositories.
There was a problem hiding this comment.
For the moment, I've created an issue.
#695
Will use more general functionality once it becomes available.
aiida/cmdline/commands/profile.py
Outdated
| import shutil | ||
| shutil.rmtree(repo_path) | ||
|
|
||
| if click.confirm("Delete configuration for profile '{}'?\n" \ |
aiida/cmdline/verdilib.py
Outdated
| set_default_profile(process, profile_name, force_rewrite=True) | ||
|
|
||
| #TODO (ltalirz) db-related functions should be moved to the base level of verdilib |
There was a problem hiding this comment.
Please add an issue for this (instead of a comment) and assign it to me unless you are interested in fixing it yourself
for running in interactive mode
…ore into fix_XXX_verdi_quicksetup
args was a tuple, needs to be list
|
@DropD Thanks for the constructive suggestions, let me know what you think |
as pointed out by Rico, --force conveys that the questions are answered in a way such as to lead to removal of the profile
|
One question/comment on this. Since we going to click for modularity and easy testing of the CLI, wouldn't it be good to start adding some tests? Especially for new commands that are developed with click? This will make our lives easier in the future. |
Please see the commit message for the small improvement to verdi quicksetup.
A few more things that are still to do:
Currently,
verdi setupprovides a default email address (aiida@localhost), whileverdi quicksetupdoesn't. If at all, it should be the other way around, but I guess a default email address is not a good idea in either case as it will mean that everybody uses the defaultCurrently,
verdi setupdoes not ask for first name, last name and institution, whileverdi quicksetupdoes. Again, I thinkverdi setupshould ask for these as well(?)