Make where "must have" files are more flexible

[viniciusalbuquerque]

What about we give the user the choice to where the credentials.json and the token.pickle should be.

Instead of just making users have a .gdrive in their home directory, we could have something that allowed users to change that more easily than going into the code.

Maybe read from an environment variable and if it doesn't exist, we default it to what we have today.

This line here:
GDRIVE_PATH = join(HOME, '.gdrive')

We could have something like:
GDRIVE_PATH = os.getenv('GDRIVE_PATH') if os.getenv('GDRIVE_PATH') != null else join(HOME, '.gdrive')
ps: I have no idea if this code above works, it's just an example.

What do you think?

[psteiger]

I think the flexibility suggested is good and I suggest we think about the approach that is most OS-agnostic. I'm not sure about how we would handle environment vars in Windows.

Alternatively, and I'm not necessarily saying it would be a better approach, we could have a config.yaml or config.json file pointing to the files, with default values. Config files could be changed by the script itself via some --set-config-dir parameter.

If we find out we could support os.getenv() seamlessly on Windows/MacOS/*nix, that's a good approach.

[CarlosRodrigo]

Flexibility is a good option. I like both ideas mentioned.

One thing to take note regarding the default values. I think we could have them stored in a folder inside the project itself. This way we could access them using a relative paths and not necessarily have to worry about differences between os.getenv() from all operating systems to figure out where the files are stored.
If the user wants to store them in a different folder however, we could have an option provided by the script to set a symlink between the default values and the value set by the user.

Also, if we ever intend to package the application and distribute it as an app the user could input the credentials.json to the app.

[psteiger]

@CarlosRodrigo, having the configs in the user home allows for 1 binary -> N users, which would possibly be a common use case if the user installs the script in a system-wide location to be shared across multiple users. That would break if we chose to put the configs in the project root.

[viniciusalbuquerque]

@psteiger Hm.. good point. If we were to choose the project root solution, we would have to have a folder for each user that wants the app configured then..

But I think we can find a way to have multiple configurations and I think they should be in the project root.

I say that because for example: if I have more than one Google account where I use the drive for each account, what we have to do now is to have two token.pickle files where one is named differently and the other is named correctly so the program know which one to get. We could try to find a way to have multiple configurations for the app.

It would be like a 1 binary -> N configurations not even taking into considerations the amount of users. That means that an user could have multiple configurations.

Maybe we could have something like:

gdrive/accounts/1/token.pickle
gdrive/accounts/2/token.pickle

And have a config.json file where we define the default account

{
    "default-account": 1
}

And we could add some new commands and parameters to gdrive itself:

gdrive set-default-account 2 -> that would make account 2 the default

gdrive upload fileX --account 2 -> that would execute the command only this time for the account 2 but the default could still be whatever.

We could set aliases to make it easier to identify which account is which.

[psteiger]

Ok.

I like the idea of 1 project root binary and each user having his .gdrive folder in his $HOME, that's how most programs work, at least in *nix. If a user has N accounts, his own configuration can support it. E.g. his $HOME/.gdrive/config.json could have

{
   "email@gmail.com": {
      "a": 5,
      "c": 6
   },
   "email2@gmail.com": {
      "a": 4,
      "c": 1
   }
}

Windows handles this in a similar fashion, e.g. Steam and AppData.

That also makes it automatic to delete user config if user is deleted from the system. If a user is deleted from a system, his $HOME is deleted, then his config is deleted. That's how it should be.

Your suggestion says that we should put account/1/tokenpickle in the project root folder. Aside from the point made above, that's also a potential security issue: if we don't take care of file/folder permissions correctly, other users would be able to see and maybe use other users token.pickle.

[viniciusalbuquerque]

Great point again!

I agree with you and I now think we should have a config.json in $HOME/.gdrive. We could extend this config.json for whatever configurations we need for the app.

{
   "download-chunksize": "X",
   "upload-chunksize": "Y",
   "configured-accounts": {
         "email@gmail.com": {
                "id": "1",
                "alias": "maybe?"
         }
   },
   "default-account": 1
}

[jrcamelo]

Completely agree with the discussion so far in regards to configuration.
But, as for this .json file, it could be a little awkward during the process of pushing commits for devs and pulling updates for users.

Perhaps we could experiment with creating this .json on the first run of the app with the default values, adding it to .gitignore.
Or alternatively, use a dotenv file for the configuration, as git ignores it by default. The downside is that the user needs to rename the file, for example, .env-TEMPLATE to .env.

[psteiger]

@jrcamelo , user config files should not be put on version control, indeed. If any, just a default json file on project root that would serve as basis for user config files generation, but maybe not even that: we could generate the json on runtime through code.