gg.cmd on PATH

[koppor]

If therew was global caching, gg.cmd could live on the path - and one could execute their favourite toolchain just using gg.cmd. This isn't an idea that bad, is it?

[eirikb]

It is not a bad idea. Others have asked for the same.
And the implementation part is simple, just go to $HOME/.cache.

But I'm not too sure if it should be global by default, or by -g, or first time config, or g but optionally set a global config.

The main reason I didn't add it was because I didn't know how it should look, and like with npm I really liked that the resources were exactly where I expected them, and could see/delete/whatnot them. The only big issue I could think of was space. It takes a lot of space, but so does my other cargo projects 🤷

Also, now it doesn't check for new versions, if you say node, it will look for a folder called node. So if you don't update your global node it will be stuck on an old one, even though you might expect it to always be latest. This is simply because calculating latest version can be really really slow.
There are ways to solve that of course, and the simplest is to just not.

[koppor]

I think, jbang shows it.

> jbang https://github.com/iloveskittles82/jabref/blob/jabmap/.jbang/JabSrvLauncher.java
[jbang] https://github.com/iloveskittles82/jabref/blob/jabmap/.jbang/JabSrvLauncher.java is not from a trusted source thus not running it automatically.

If you trust the url to be safe to run you can do one of the following

(1) Trust once: Add no trust, only allow access to this URL for the duration of this run
(2) Trust limited url in future: https://github.com/iloveskittles82/jabref/
(3) Trust organization url in future: https://github.com/iloveskittles82/
(0) Cancel

[jbang] Type in your choice and hit enter. Will automatically select option (0) after 30 seconds.

In terms of directories, it would be

(1) Trust once: Add no trust, only for the duration of this run
(2) Trust this command now and in future
(3) Trust this directory now and in future
(0) Cancel

[koppor]

Isn't it pretty obvious? If the global cache exists: use it, if not then not? The flag -g initializes the global cache. As a concequence: If a user never uses -g, no global cache is every initialized. If a user uses -g once, there is always a global cache.

Maybe, I am overlooking something, but a global cache has only benefits. - The only drawback I could think of, if the hoem directory is mounted on Windows and synchronized. Then, the cache should be placed somewhere else. On windows, the global cache should be in %LocalAppData%/gg.cmd 😅

Example content of that directory:

[eirikb]

I'm not sure if -g should initialize it. I'm thinking more it should be per-call.
To initialize config and set it permanently something like this perhaps

sh gg.cmd config global true

[koppor]

The config command seems to involve some config management; which isn't there yet, is it? 😅 - For sure, that is more transpareant to the user then...

[eirikb]

The config command seems to involve some config management; which isn't there yet, is it? 😅 - For sure, that is more transpareant to the user then...

Yeah I'm making stuff up.-g doesn't exist either - Yet!

[koppor]

For me, the "magic" re-use of the global cache would be very OK - it saves space. And in my applicaton, JDK would not be downloaded twice. (Once for the jgit-based clone and once for running gradle)

[koppor]

Regarding the caching - it's already explained in the XDG-spec - number 12 in https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46:

For cache files though, use ~/.cache/myapp on Unix but on MacOS it’s better to default to ~/Library/Caches/myapp. On Windows you can use %LOCALAPPDATA%\myapp.

[eirikb]

So you are saying it would be best to use global cache as default?
Perhaps it is for the best...

[koppor]

Global caches as default would be great!

Will make the GitHub action a bit harder (because depending on the OS different paths need to be cached), but I think, its worth the effort. - I remember slow network drives; or even slow WSL mounts to Windows.

[eirikb]

Instead of an optional -g it could be an optional -l for local cache. This would work in CI/CD?

[koppor]

-l is a nice idea!

[koppor]

Currently, with absolute path does not work:

[eirikb]

This is related to #92 (comment) right? I did a test and might have a fix. I haven't pushed it because I wanted to test it on Windows... Perhaps I'll just push it later anyway

[koppor]

This is related to #92 (comment) right?

Seems like 😅

I did a test and might have a fix. I haven't pushed it because I wanted to test it on Windows... Perhaps I'll just push it later anyway

I can test (but maybe not be able to build a branch 😅🙈)

[koppor]

If this is implemented, README.md could contain that tis is a replacement of GNG.

[koppor]

That's the idea yeah, by default you can put gg.cmd in ~/bin, and when you run it it will put cache stuff in ~/.cache/gg . Unless you send in the -l flag (as we discussed) then it will put the cache elsewhere.

I'm not sure what would be most correct in that case, either gg.cmd location or pwd - or as you say gg.cmd with write-check and fallback to pwd.

I would say: -l. because this is is not "hidden" from the user's perspective...

There could be also -gl for gg-location; but this feels too special. I can't think of any case where this is useful ^^

[eirikb]

What if there is a .cache/gg folder present (because of earlier versions of gg, or previously run with -l) - should it automatically pick this over global, even when no -l is provided?

[koppor]

What if there is a .cache/gg folder present (because of earlier versions of gg, or previously run with -l) - should it automatically pick this over global, even when no -l is provided?

Difficult 😅

Has to be a reason that a user has a local cache.

Idea: It should pick it and output "using ./cache/gg"

[eirikb]

I've been trying to have as little output as possible (especially when everything is ready) in favor of the tool gg.cmd tries to run.
But in this case I agree. Use local cache but tell user, if -l then no output, and if global (default) then no output.

[eirikb]

Ok so I've pushed global support. It came in 104, with some additional fix in 105.
I've decided to not do anything about local .cache (for now at least). Meaning no flag = always global, even if there is a .cache folder. And -l will always use local

[eirikb]

This should work now. Closing