Change path to credentials file

[oshliaer]

Hi!

• How to change path to credentials file?
• Is there the best way to override defaults.STORAGE_FILE there ?

I work with local installations. I can not use the% USERPATH%.

Your apps is great & helpful. Thanks.

[willpatera]

My question overlaps with @oshliaer's first two bullet points.

For example, if a developer is working on two (or more) projects simultaneously and wants to be able gapps auth without having to delete ~/.gapps -- what would be the best workflow?

[hess-g]

If you are working on multiple projects under the same user account, then you only have to do the auth process once. If you are doing simultaneous projects under different user accounts, then you have to have an OAuth authorization for each, which isn't currently supported (but could be investigated).

As for the path issue, auth is supposed to be global; i.e. the -g install can take advantage of auth that only needs to be done once. That requires some "common" location, and the user home seemed to be the most logical. Alexander - Do you have any thoughts as to implementation of an alternate location?

[willpatera]

Hi @hess-g - any ideas about how to support simultaneous projects under different user accounts?

[hess-g]

That's tricky. Neither of the two possible execution contexts (global install, or local install / "require" use in a node task runner) have access to your "intended" user ID. I'll have to don the thinking cap for a bit on this one...

As you noted above, the workaround today (worst case, I know) is that you have to do the process auth before you start working against a particular project context. Yes, that would make it a bit more painful if you have to rapidly switch contexts, but it is possible.

[oshliaer]

Ok. Let me explain the goal.

My npm-instalation is --save-dev locally. I have to push code on behalf of the various accounts (Consumer and Google Apps). Now I'm not doing rocket. I simply override a line of code. I set return 'PROJECT_PATH' It works perfectly.

But I like to use npm. There is an example with npm run-script An idea for overwrite .gapps file path

[hess-g]

That looks good. Can you submit a PR with that change?

[oshliaer]

@hess-g , I can do it. My fears are that I'm using npm run. Do you think it's a good habit? I'm not very familiar with the rules of decency in open source.

[hess-g]

Yeah, I see that now. The main challenge is that, whatever the implementation, it needs to support both the run-style (command line exec of gapps) and node js (var x = require("node-google-apps-script"). Some more thinking is needed here...but your gist did spark some ideas.

[0cjs]

Here are my thoughts on the matter.

1. The .gapps file with a JSON data structure in it is the right way to store authentication information.
2. .gapps is in the right place ($HOME) on Unix. On Windows, it's probably in the right place, though I could see someone making an argument that %APPDATA%/Roaming or whatever should be used instead. (That's really something for the Windows experts.)
3. .gapps (and the auth command) should be extended to store authentication information for multiple accounts, identified by the Google account name (e.g., [email protected] or [email protected], to give examples of two actual account names).
4. The gapps.config.json file should be extended to associate one or more Google account names with each fileId[1] so that it can figure out what authorization materials to choose from $HOME/.gapps. This should be specified as a single account name, a list of account names, or a single or list of regular expressions. The regexps are useful for dealing with the case of, e.g., a shared production document that both [email protected] and [email protected] are allowed to update; specifying just /@example.com$/ will allow both of them (and any other example.com developers) to work with a common configuration.

[1]: Though we don't do this at the moment, in the long run we want to be able to store multiple file IDs in the gapps.config.json so that we can handle having, e.g., separate testing and production documents. This is discussed a bit in the discussion in PR #28

[jruusu]

Created for my own deployment tooling needs, minimal multi-env support: PR #48

[oshliaer]

Thanks @jruusu!