Lack of "download" Command

[0cjs]

(Note: I believe that what I'm looking for here is not at all the same thing as #19, in particular because I'm looking for functionality that is not the same as the 'clone' command.)

Let me start by saying that I agree that, generally, the git repo should be the authoritative source of the code for a GAS project.

However, I'd like to be able to check that, when I have checked out what is supposed to be the released version of the source, the actual released version matches that. The first idea that comes to mind is to be able to run "gapps download", which would use the information from the gapps.config.json file to download the currently released copies of the project, and then a "git diff" would tell me my version is inconsistent and, if so, what those inconsistencies are.

I'm open to other ideas for how to do this, though.

A further extension of this would be the ability to download specific versions of the project as saved in "File / Manage Versions..." dialogue. However, I don't see any API that would let us do this, nor am I sure that the usefulness of this would justify more than very minimal expense.

[0cjs]

I've submitted a pull request with a fix for this:
#28

I suspect the coding style is, er, "sub-optimal" because I barely know JS/node/Promise/etc. from my arse, but I'm happy to get advice on making it more acceptable. Best thing is to poke me via text chat; see the URL in my profile for contact information.

[danthareja]

Hey @cjs-cynic-net thanks for your issue and PR. I'll be reviewing it soon!

[0cjs]

I just wanted to check where we stand on this. Have you had a chance to review it yet?

It would be convenient for me if this could get pulled in to the master branch and released at some point in the not-too-distant future, as it would make it easier to integrate comparison of the server copy and local copy in to my build scripts.

[danthareja]

Sorry about the delay on this one. This is an interesting proposition for the download command, but I'm not 100% convinced yet that this functionality is the responsibility of the gapps tool. If you push to version control every time you run gapps upload, there should never be any diff. This could be handled by including gapps upload as a pre-commit hook or any step of a modern tooling chain.

Can you tell me more about a specific time when this was a challenge for you? I'm wondering if there are other tools that could be used to solve this problem.

[0cjs]

There are two major problems with your reasoning.

First,

If you push to version control every time you run gapps upload, there should never be any diff.

There are simply too many different ways for things to go wrong with this to say, "I'm not going to support checking for errors." Not only might there be synchronisation issues between different copies of the repo on different machines, but the code on Google itself can easily be changed without going through the repo at all.

Your approach is like saying, "we won't provide any ability for automated testing in this project because if you are careful you can get your code right the first time, and never break existing code."

Second,

You're working on the assumption that there's only one apps script project on Google Drive, which is clearly impractical in a multi-developer configuration. The very post you reference in your README, Advanced Development Process with Apps Script, recommends that each developer use a separate apps script project for their own development and testing:

...the biggest improvements you get by working outside the script editor is that you are no longer locked into working in just one Apps Script project. You can much more easily collaborate as a team, with individual developers having their own working Apps Script projects...

Your tool doesn't support this yet, but I have plans to add such support.

If this sort of stuff doesn't appeal to you, do feel free to let me know. I'd prefer not to fork the project if I don't have to, but if your development processes are significantly different from mine (which are based on a couple of decades of experience, BTW) it may be better just to have different versions for different approaches.

[hess-g]

(disclaimer - I authored the "Advanced Development..." post referenced above).

On > n Apps Script projects: The sample that was authored for the post does in fact demonstrate how multiple Apps Script projects can be used with this tool. The simplicity of the tool allows a development team to decide just how they want to approach that, without taking a strong prescriptive stand. That's one reason why I referenced this tool in the article.

On including "pull latest from Apps Script" in this project: When using this tool as part of my own development workflow, I treat the target Apps Script project as I would any compiled binary - I can rebuild it from source at any time. If I am working in Java, .Net, or other compiled languages, I don't expect to be able to unwire the binary to compare against my source. Yes, Apps Script is a different case, as you have the capability to edit the source in place in the Script Editor. If using this tool (or something like it), and the processes that go along with it (which should mirror development practices for other compiled languages), then you just don't do that. The person in deployment manager role shouldn't care that code edits where done in the editor, nor should they allow anyone on their development team to. That is akin to someone slipping a rogue binary build into one of your environments - when you deploy your latest "valid" package, that rogue change is gone...and no one should complain about it.

So, my $.02 is that this tool, as it stands, with it's simple ability to push code to a target Apps Script file, works well for the dev processes I've outlined. Your opinion may differ, which is 100% valid. Whether additional functionality should be added to this project is ultimately Dan's call, taking into consideration all of the points on this thread.

[0cjs]

Re > n Apps Script projects: I agree we definitely want the flexibility for developers to choose their own structure for handling multiple scripts projects, I think that it's a frequent enough occurrence (given that it's recommended practice) that putting some common code to help deal with this in gapps itself is a good idea. Without that, everybody's going to be rewriting similar code, with all the problems that entails. I think that with a bit of cleverness in design of the config files (such as allowing the developer to provide a function matching a certain API in place of a static data structure) developers would have just as much flexibility in the design of their build system but be able to leverage common code for multiple configurations in almost all cases, and in many simpler cases, not have to write their own tools to deal with multiple configurations at all.

Re "pull latest from Apps Script": you're free to treat the server-side GAS project as a "compiled binary" if you like, but it's clearly a different thing. Workflows where someone comes back to you and says "I did an emergency fix on the compiled binary on your server" are nonsensical in things like C++ development, but not only possible but even sometimes reasonable in GAS. For example, when I'm playing around with a GAS API, I sometimes simply tweak code directly in the GAS project in my web browser window and run it using the 'Run' menu item; the turnaround on this is several times as fast as changing it on a local checkout and doing an upload every time. It's nice, when I've had to do "debugging"-style work like this, to be able, once I've fixed something, to immediately download my results.

And again, while it's laudible to say you should never have anybody modifying stuff directly through the web browser itself, to say "we're not going to support methods for easily detecting these changes" is quite a different thing. People should never do things that start fires, but we don't say that because of that we don't need fire extinguishers in buildings. We admit that mistakes happen and create systems that minimize the damage when they do.

Anyway, I can see enough pushback on this project here, and lack of response in other areas, such as automated testing, that you've convinced me that it's probably best to fork the project, at least for the moment. I'll send a couple more pull requests so you guys can get a sense of what I'm doing, and if you guys change your mind you could start pulling them in.

[danthareja]

Hey @cjs-cynic-net, I really appreciate your input here. To be totally transparent, this tool was initially developed for my own personal use at work, and has reached a wider audience with the help of @hess-g. My initial pushback arose because I don't use this tool in a large team setting, and I don't think I'll ever be the authority on the issues you're experiencing.

I do agree with many of your points, but I don't have the time right now to commit to the work it would require to make these changes. I'm happy to see you fork the project to suit your needs and look forward to your PRs should you choose to submit them

[brainysmurf]

I am using this tool to maintain a potentially large code base as well, and I have to agree with c-j-s.

The stack we are using is quite unique. In other environments, our local stack can be assumed to work exactly like the remote one (with important caveats). But with Google, if something isn't working right with different calls to Google's API, it just makes a whole lot of sense to modify the code in the script and test in the remote stack. (Using the Test as Add on...) You can mock them locally, too, to avoid having to do this all the time, but if you got that mock wrong you need to go to the source.

Granted the programmer could potentially screw this up. How about a --force option and without it, it prompts the user with "are you sure..."?