Add `depot-dir` action about goa HOT 6 CLOSED

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).

from goa.

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.

from goa.

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.

from goa.

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.

from goa.

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.

from goa.

Implemented by 85ea260

from goa.