config file usage?

[prarit]

Hey @zaquestion,

There are a few features for which I will need to use the configfile. I'm not sure if there any restrictions on using it ATM and want to get clarification for it's use.

Here are some of the things I'm thinking of using the config file for. Please note my examples are in a gitconfig format and I do understand that the lab configfile is in hcl. The gitconfig format just seemed easier to type :)

a) Storing gitlab personal access tokens

Instead of storing them in text I think the way to really do this is to implement something like

[token]
gitlab.com = pass show gitlab/token

so that lab could have multiple gitlab instance's tokens stored.

b) Alias'ing commands

Similar to git-alias, the config file would be a place to store lab alias commands. For example, instead of a 'git mr show --patch' command (which would create the patches for a merge request), an alias of something like

[alias]
mr-show-patch = !sh -c 'mr checkout; git-format-patch'

keeps the amount of code we have to worry about to a minimum.

c) Highlighting new comments

One of the features that is lost with an email based git workflow (ie the kernel) is the ability to keep track of new comments. In a mailer this is easy because the new comments remain unread but in a text-based console it's not so easy to do.

I've been toying around with a 'mr show --since' option that highlights "new" merge request comments [1] . For example, 'lab mr show 9 --comments --since "2020-08-21 00:08:15.318 +0000 UTC"' would only show comments that were added since Aug 21 @ 8:15 AM. It's actually easy to code using github.com/fatih/color.

After implementing --since I realized that I had created a bad user experience as users have to remember the date they last viewed an MR or Issue. After thinking about it some more a better approach is to keep some metadata (that can be flushed every so often so it doesn't get out-of-hand) that simply stores the last time an MR or Issue was displayed on the console. The lab command would read the stored value and highlight new comments since that date.

This would have to be opt-in as I can definitely see not every user caring about highlighting of new comments.

So something like

[show-metadata]

gitlab.com/project-name mr 8 = 2020-08-21 14:57:46.808 +0000 UTC
gitlab.com/project-name mr 200 = 2020-08-20 11:12:12.511 +0000 UTC
gitlab.com/project-name issue 12 = 2020-08-16 09:45:11.612 +0000 UTC

The data could be cleared for CLOSED/MERGED issues (on linux via systemctl timers, cron, or atd) nightly or through a command line option, 'lab clean-metadata'.

[1] https://github.com/prarit/lab/tree/mr_show_since

In any case, while the individual examples each should be their own issue this issue is about whether or not the config file is available for general use or not.

P.

[zaquestion]

We can expand on the config file. Long term I want to rip out hcl, which hasn't actually played as well with viper as one would hope. The code to work around that is real nasty in lab. You may find it generally unpleasant to work on the config code. If you want to move with more broad strokes in mind I might suggest creating a new config directory ~/.config/lab/config.<something> and going from there, yaml or json should both work better with viper (namely the automatic env vars features is what we're looking for.

a) A way to execute a command to retrieve a token in place of a plaintext one sounds great, so long as we can do it in a backwards compatible way. Even if this mean simply offering an alternative key to provide creds under. Can be followed up on in #382

b) For 1.0 I'd ideally like to remove aliasing lab to git through lab itself, and instead use the git-alias and "git autocomplete behavior" (git-lab binary becomes git lab) to implement aliases. Historically I've felt that aliases are better left to the shell or git tool. Can you elaborate more on why we should bring them here over using these other mechanisms? It seems like any functionality can be replicated through either shell (bash, zsh, etc) aliases or using git-alias?

$ git config --global alias.mr lab mr 

^ Similar approach to how googles git-codereview tool works https://pkg.go.dev/golang.org/x/review/git-codereview?tab=doc

The idea being that lab is adjusted to have a command that adds them for you. I suppose if the configuration was implemented this way it could be reasonable to manage...

c) We've talked about storing things like metadata before, I'm totally into it. I'd suggest leveraging ~/.local or ~/.cache. I'm hesitant to using the repositories .git as proposed in #405, that seems like a bit of an overstep on our part (even tho write in that directory for temp mr/issue/snippet create messages already).

[prarit]

We can expand on the config file. Long term I want to rip out hcl, which hasn't actually played as well with viper as one would hope. The code to work around that is real nasty in lab. You may find it generally unpleasant to work on the config code. If you want to move with more broad strokes in mind I might suggest creating a new config directory ~/.config/lab/config.<something> and going from there, yaml or json should both work better with viper (namely the automatic env vars features is what we're looking for.

FWIW I found using hcl a bit clunky as well. It doesn't lend itself to easily making hand edits like the .gitconfig files do. Let me get through #405 and for the longer term I can concentrate on finding a better config tool. I'd like it if we could have a .gitconfig format as that seems natural to use.

a) A way to execute a command to retrieve a token in place of a plaintext one sounds great, so long as we can do it in a backwards compatible way. Even if this mean simply offering an alternative key to provide creds under.

I think a way to do this would be to read the token to see if it "looks" like a token. There are other cases of this in code where they check to see if a git hash is, in fact, a git hash. If the token is a token then it could be used as straight text. Otherwise let's assume a command is written there. I think I could test with this pass or some other password manager.

b) For 1.0 I'd ideally like to remove aliasing lab to git through lab itself, and instead use the git-alias and "git autocomplete behavior" (git-lab binary becomes git lab) to implement aliases. Historically I've felt that aliases are better left to the shell or git tool. Can you elaborate more on why we should bring them here over using these other mechanisms? It seems like any functionality can be replicated through either shell (bash, zsh, etc) aliases or using git-alias?

$ git config --global alias.mr lab mr 

^ Similar approach to how googles git-codereview tool works https://pkg.go.dev/golang.org/x/review/git-codereview?tab=doc

The idea being that lab is adjusted to have a command that adds them for you. I suppose if the configuration was implemented this way it could be reasonable to manage...

This is a better direction to move to. . Never mind b) :)

c) We've talked about storing things like metadata before, I'm totally into it. I'd suggest leveraging ~/.local or ~/.cache. I'm hesitant to using the repositories .git as proposed in #405, that seems like a bit of an overstep on our part (even tho write in that directory for temp mr/issue/snippet create messages already).

I've seen other tools use .git for the purpose of keeping per-repo data. While it's not written anywhere, it seems like it is okay to do so long as we don't stomp on any of git's data. IMO the likelihood of a namespace collision between lab and git is zero.

As for #405 it seems logical to keep the mr and issue access times per repo, and my decision to use .git was based on the additional complexity of looking in ~/.config or ~/.local. I wanted an easy to find location for the data to help with debugging, allow possible hand editing of the file, etc. I was also thinking about what happens when someone checks out multiple copies of a repo, or moves repos. I don't think I'll be able to keep track of the data.

If you feel strongly about it I can certainly look into using ~/.cache but I do feel pretty confident that using .git isn't an overstep on our part. Other tools are using it and haven't had any problems.

[prarit]

I spoke with a few 'lab' users about the pros-and-cons of using a ~/.config or ~/.local based configuration setup vs a .git setup, and there are some good arguments on both sides. However there are a couple of use cases that would clearly break and/or require additional steps.

With larger projects like the kernel, gcc, and python it is common to check out the repo and use the repo remotely (either by moving it or by nfs-mounting). In the case of nfs-mounting of large projects the location of the metadata would be lost across the mount.

One person also added "There's always going to be a need to store some local data in the repo that you cannot get around."

I'm not saying we must do this now but it might be better to try this now with this limited use case.

Thoughts?

[zaquestion]

re: General Config -- I hammered out a quick issue to track this moving forward: #407
A) See #382
B) 👍
C) Sounds good, I'm onboard with using .git for this now, appreciate talking it out, that's really what we're looking for when making these kinds of decisions.

Semi relevant Xpost from #405 for context

First I'd like to go with either a lab_ preview to file names or place files in a .git/lab/ directory (leaning towards the later). Second, does metadata make sense to describe whats being stored in this file? It's certainly metadata, but it's also specific to lab issue/mr show operations, so something describing that seems preferred. Perhaps .git/lab/show_op_log or .git/lab/cmd_show_metadata or .git/lab/show_metadata (with w/e extension)

Let's go ahead and leave this issue open until #405 comes in, and post back with whatever we come up with, then we can close it out.

[prarit]

appreciate talking it out,

I'm not going to make any medium or major changes without your approval. Small changes, bugs fixes I'm okay with merging but beyond that I'm not going to self merge unless I get a signoff.

[prarit]

So I think this has been resolved in lab with MR 397 and 416.