load the username into the metadata about diffpy.labpdfproc HOT 16 CLOSED

For the first time of using it, as there is no username and config file created, give an error and then use another function called "set_username" to create the config file in the given config directory.
Otherwise, load username from the given config directory and load the username config file.

from diffpy.labpdfproc.

For the first time of using it, as there is no username and config file created, give an error and then use another function called "set_username" to create the config file in the given config directory. Otherwise, load username from the given config directory and load the username config file.

Taking a tip from Git, maybe don't error, but allow the user to continue without entering the name/email but always show the annoying message and require the extra step until they do run the config program.

from diffpy.labpdfproc.

UC 1 CGS uses device username to load for the first time

1. chem grad student (CGS) use the labpdfproc (LPP) for first time. He/she uses their own device, which has a username.
2. By default, LPP find the directory and config file and cannot find it. (Due to first time loading) LPP gives a message that asks user whether set LPP username the same as device username. [y/n].
3. CGS chooses yes, then LPP creates config file in the config directory.
   ========

UC 2 CGS declines to use device username to load for the first time

1. The same as 1.1
2. The same as 1.2
3. CGS chooses no, then LPP gives a warning message: "You could set your username..." CGS could close it use the app normally.
4. For subsequent usage, if still declines using the system device username, 2.2 2.3 would always show until CGS set username successfully.
   ========
   ###UC 3 CGS uses LPP with username in existing config
5. He could directly use LPP without showing any message.

If CGS want to overload username, they could use terminal with specific command to overload username to change it in the config.

from diffpy.labpdfproc.

UC 1 CGS uses device username to load for the first time

1. chem grad student (CGS) use the labpdfproc (LPP) for first time. He/she uses their own device, which has a username.

2. By default, LPP find the directory and config file and cannot find it. (Due to first time loading) LPP gives a message that asks user whether set LPP username the same as device username. [y/n].

3. CGS chooses yes, then LPP creates config file in the config directory.
   ========

UC 2 CGS declines to use device username to load for the first time

1. The same as 1.1

2. The same as 1.2

3. CGS chooses no, then LPP gives a warning message: "You could set your username..." CGS could close it use the app normally.

4. For subsequent usage, if still declines using the system device username, 2.2 2.3 would always show until CGS set username successfully.
   ========
   ###UC 3 CGS uses LPP with username in existing config

5. He could directly use LPP without showing any message.

If CGS want to overload username, they could use terminal with specific command to overload username to change it in the config.

Thanks Steven, great job. I am not sure that we want to query the system tbh. computer user-names are notoriously bad and so we will end up with lots of bad data inputs. I think my suggestion would be:

###UC 1 CGS uses device username to load for the first time

1. Chem grad student (CGS) use the labpdfproc (LPP) for first time on their computer
2. LPP is unable to find a config file
3. LPP requests the name of the User, explaining this will only be asked for once and why it is requested and that it can be updated manually later
4. CGS enters their name
5. LPP asks for user email with similar explanations
6. CGS enters their email
7. LPP writes the information in a config file in the user's home directory (~/.config/diffy ?)
8. LPP adds the information to the metadata
9. LPP continues on and does the analysis

from diffpy.labpdfproc.

Additionally, I think loading email follows the same procedure as loading username as they could be load into the config together.

from diffpy.labpdfproc.

that's right on the email. This is captured in the UC I wrote.

It also just occurred to me that we could actually try and sneakily get the information from the git config file.  I guess not so many people use git, but those that do should have their git config set up with name and email so we could, as a first cut, go look in there.  We should think if this is what we want to do (and we should tell the user we are doing it) but the UC would be something like:

###UC 4

1. CGS runs LPP
2. LPP can't find a diffpy config file
3. LPP looks for name and email in a git config file
4. As my UC1.3-1.9 but the program offers as defaults the values it finds in the git config file

Also
###UC 5

1. As UC 4 but an additional question is asked allowing the user to enter their ORCID identifier

Note with UC 5, if the user doesn't supply this, we don't keep asking for it, but in the documentation we give instructions about how to add it manually later. We could write a little config program too that allows the user to update the config file from the command line but I am not sure if that is worth it. For now, let's just write instructions in the docs about how the user can edit their config file directly.

Second note, we have a whole suite of diffpy programs but this is the first time we have thought about a config file. I suggest for general things like user name and email we put htem in a diffpyconfig.json file or sthg like that (or use the same format as git for the config file?). If there are user config things specific to one of the other programs we could extend it (in the future, not here) with labpdfprocconfig.json for example.

from diffpy.labpdfproc.

@yucongalicechen please add any thoughts you have, but I think this is coming together to my liking. I am inclined to have @stevenhua0320 implement UC5?

from diffpy.labpdfproc.

OK, I would implement UC5 when I figure out the structure of how to implement in python. @sbillinge

from diffpy.labpdfproc.

Maybe one thought is that everything remains the same for UC1, except that CGS want to enter more than one username, or one username per datafile? But I'm not sure if this becomes too complicated and in this case it might be better just to run the program again.

from diffpy.labpdfproc.

Maybe one thought is that everything remains the same for UC1, except that CGS want to enter more than one username, or one username per datafile? But I'm not sure if this becomes too complicated and in this case it might be better just to run the program again.

I think there are two questions here.

1. Do we give the users the opportunity to override the default user-name and email at runtime, and
2. if we do, do we give them the opportunity to list more.

Deciding questions like these is usually done by thinking about what the users might want. I think they might want something like this, so they can upload a list of users, for example, if there are multiple people at an experiment and they want them all listed.

So I think the answer is probably yes, let's let them enter this info at the command line as an option that overrides the default behavior, and why not let it be a list then.

If it is a group of people at a beamtime, for example, it would be a drag to have to enter the names every time you run the program. Maybe we want to have a config file in the current directory with the same format as the default config file. The priority would be that quantities entered on the command line override quantities found in the local config file, which override quantities found in the config file that is in the user-home-directory.

Then we need documentation describing all this. Right now, the only docs we have are help strings in the arg parser and docstrings in the functions, so let's at least put the info there.

from diffpy.labpdfproc.

@stevenhua0320 do you want to pick through this and come up with an implementation plan (i.e., what functions do what where) and jot it down in a comment, then you can start to draft tests that test that behavior and put them into a PR that links to this issue.

from diffpy.labpdfproc.

For UC5 (independent from the other attributes like username, email etc. since they could be run in another test to test the behavior),
we need to define a boolean that reflects whether user agrees to provide ORCID ID.
the load_orcid function would take the args and load the info into config file of user.

param = [([orcid_permit = False, orcid_id = ""], [""]), #since user don't want to provide orcid number, return nothing
([orcid_permit = True, orcid_id = "args with 16 digit number"], ["orcid_id"])]

test_load_orcid(inputs, expected):
actual_args = get_args(inputs)
actual = load_orcid(actual_args)
assert actual.orcid_id == expected

In addition, we need to test some bad inputs
param2 = [([orcid_permit = True, orcid_id = "args with fewer than 16 characters"], ["please provide valid ORCID number."]),
([orcid_permit = True, orcid_id = "args with character other than number"], ["please provide ORCID number in valid format."])]

test_load_orcid_bad(inputs, expected):
actual_args = get_args(inputs)
with pytest.raises(ValueError, match=msg[0]):
actual = load_orcid(actual_args)

from diffpy.labpdfproc.

I doubt we need a load_orcid function. We are loading, name, email and, optionally, orcid. It doesn't require a special function for the orcid. No bool is needed.

So what we are looking for is a design for how to do all the UCs that we want to implement. As before, the first question is which UCs to implement. I guess we want to do Simon's UC1,and UC4 for now.

the pseudocode would be something like:

find_conf_file()
args = get_args()
if conf_file exists:
    read it 
    if it contains user_name and user_email:
        load into args
    else:
       user_info_conf()
else:
   user_info_conf()

then we need some words explaining what find_conf_file() will do (it will look for a conf file locally, then in user_home and return the full path.

user_info() will query the user for name, email and orcid. If it receives a valid input it will save it to a conf file in the user login directory. It will also load it into args. Othewise it will do nothing and continue.

from diffpy.labpdfproc.

So, you mean that as long as the user has its username and user_email in the git config file, we load all the info into args, optionally if it has orcid it would also be loaded.
What we left is to define find_conf_file() to get the path of the config file that we want, and user_info() to manually get username and email.

from diffpy.labpdfproc.

from diffpy.labpdfproc.

@stevenhua0320 I think you are ready to start putting some code into your PRs now. Please can you start by writing actual tests for the things. Now you have a better idea of what the objective is in each case, try and write an actual test (not pseudocode) to capture the behavior. Sometimes it is possible to understand the intent of the test just by reading the test. But sometimes a small comment that describes what the test is testing (please see Yucong's tests to see what I mean) can be very helpful.

from diffpy.labpdfproc.