Add `depot-dir` action

[jschlatow]

By default, Goa creates a default depot at var/depot in the project directory. This is done "magically" when Goa tries downloading/extracting any depot archive and encounters a non-existing var/depot directory. However, when calling goa export, the var/depot folder gets created but will not be populated with the default depot users. The same effect occurs for goa add-depot-user.

By introducing a depot-dir action similar to the build-dir action, we could make the goa run, goa export and goa add-depot-user dependent on this. Moreover, the action could be used separately to initialise a certain directory as a depot.

@nfeske I noticed that Goa only populates the depot directory with the default depot if the depot_dir configuration has not been customised. I'm wondering whether we could change this. When working with several projects, the --depot-dir argument or depot_dir config variable can be used to use a shared depot directory. However, there is no way to conveniently set this up.

[nfeske]

It makes perfect sense to turn the depot-dir creation to a dedicated Goa step.

With the conservative policy regarding the installation of the default depot users I wanted to balance two points:

1. New users should be able to follow the Goa tutorials without any manual steps for setting up depot keys and download files (via goa add-depot-users. So goa run just works without a second thought.
2. Proficient users may want to have fine control over which packages to download from where. So when connecting Goa with an existing depot, the automated installation of Goa's default depot users into this depot may be taken as overly intrusive.

Maybe I'm too cautious with my second point?

Should you favor to always install Goa's default users, also into an existing depot dir, I'm not strongly against it. From a trust perspective, by using Goa, Goa is trusted anyway and we as Goa authors put trust in the default users curated by us. If a proficient user wants to be more rigid, it is easy enough to maintain a fork of Goa with the default users adjusted.

Alternatively, to make the behavior of Goa more consistent/convenient while keeping the conservative policy as motivated by the second point, could we consider the installation of the default keys as an explicit command, like goa depot-defaults? This could be implicit when creating an entirely new depot dir (to keep the first point addressed) while easing the preparation of an existing depot with Goa's default keys. By letting this command unconditionally install the defaults of Goa's current version into an existing depot dir, the default pubkey and download files can be easily updated from one Goa version to another without requiring much manual intervention by Goa users. Maybe the goa depot-defaults could be the same command as goa depot-dir to avoid the proliferation of too many commands (I haven't thought this through).

[trimpim]

I like this idea of having the depot-dir command that helps "manage" depot related things for a project. As we use a repository that contains different projects, I could imagine it working as follows:

• depot-dir --copy-defaults copies the default users
• depot-dir --set <directory> set the depot_user variable in the .goarc file
  • Optional parameter --goarc <file_location> specify the .goarc file to modify
• depot-dir --get could return if and where the depot_user variable is set
• depot-dir --remove-default Optional remove the default users

For me the second point that @nfeske raised hasn't been and issue so far. I always had the absolute control which packages should be used, even when the default depot users were installed.

[nfeske]

Thanks @trimpim for sharing your perspective.

As a matter of principle, Goa should not touch any goarc file because those files express the will of the user. Therefore the user should be the only one in charge of modifying them. It's similar to how I wouldn't want vim to touch my .vimrc file, or bash touching my .bashrc file.

[jschlatow]

Thanks @nfeske and @trimpim for your feedback.

I'm not sure about the point whether to install the default depot users into an existing depot. It feels a bit unexpected. Yet, what Goa misses so far is to install the default depot users if --depot-dir points to a non-existing depot. As there doesn't seem to be a rationale behind this, I am going to change this behaviour.

Maybe we could let the depot-dir action evaluate the --depot-overwrite switch to force installation of default depot users into an existing depot.

[jschlatow]

Maybe we could let the depot-dir action evaluate the --depot-overwrite switch to force installation of default depot users into an existing depot.

I must correct myself. When the depot-dir action is executed as a dependency of, e.g., goa export. It would be quite surprising if this installed the default depot users into an existing depot.

[jschlatow]

Implemented by 85ea260