Add --auto-update flag to allow automatically updating the cache

[rnestler]

When not updating the cache manually one often gets the following
message:

Cache wasn't updated in 30 days.
You should probably run `tldr --update` soon.

The auto-update flag allows to just alias tldr to tldr -a which will
automatically update the cache if it is older than the maximum age.

[dbrgn]

Nice, thanks!

[dbrgn]

I think it would be good to print an information if the cache was successfully updated:

if !args.flag_quiet {
    println!("Successfully updated cache.");
}

[rnestler]

Yes, but since I don't abort with the '-a' flag when updating fails I'll need to do it with a .map call.

[dbrgn]

Yes, or match :)

[rnestler]

I did it with map, didn't see your comment before.

[dbrgn]

To be honest match would be much more readable in this case. Don't you think?

[rnestler]

I love the bike-shedding here 😆 I don't like the double OK(_) pattern with the somewhat unrelated if guard, but I don't care that much. Just decide for the style you prefer most 😃

[dbrgn]

Well, you argued with length, and this version is shorter. And I love my bikeshed in darker hues of blue! Light blue is just abhorrent...

[dbrgn]

And if you prefer it, you can also use this:

match cache.update() {
    Ok(_) => if !args.flag_quiet => {
        println!("Successfully updated cache.");
    },
    Err(e) => match e {
        CacheError(msg) | ConfigError(msg) | UpdateError(msg) => {
            eprintln!("Could not update cache: {}", msg)
        }
    },
}

I think that's actually the nicest shade of medium blue 🙂

[rnestler]

@dbrgn Ping. I applied your favorite shade of medium blue 😉

[dbrgn]

Sorry, I've been sick for the last three days. Will take a look in a few days.

[dbrgn]

Thanks for the update.

I thought about this PR a bit. I'm still not sure if the command line flag is the right place for such a setting. It's not something you would want for some command invocations but not for others, so the config file would probably make more sense, right?

This would require a slight reorganization of the main function, but much less than I initially thought:

• Handle args.flag_config_path and args.flag_seed_config right after handling args.flag_version (simply move up the code blocks)
• Move the config loading code in print_page into the main function, right after the args.flag_seed_config handling block
• In src/config.rs, add the new config elements to the RawConfig and Config structs and add the defaults to RawConfig::new().

The default configuration can be generated with tldr --seed-config. My suggestion would be:

[updates]
auto_update = false
auto_update_interval_hours = 720

(The auto_update_interval_hours could then be set to MAX_CACHE_AGE * 24 by default.)

What do you think? Sorry for the change request, but every new flag is a maintenance burden because removing it later is a breaking change, so I want to think twice before adding such new flags...

[rnestler]

What do you think? Sorry for the change request, but every new flag is a maintenance burden because removing it later is a breaking change, so I want to think twice before adding such new flags...

The same is true for config options 😉 But probably we want to think about the general configuration concept. Some tools have almost every option configurable via command line, config file and environment variables. But this may or may not make sense for tealdeer.

But for the auto update the config file probably makes most sense since it is a rather static option.

[dbrgn]

But for the auto update the config file probably makes most sense since it is a rather static option.

👍

[devnoname120]

Any updates on this?

[dbrgn]

Any updates on this?

The changes outlined in #73 (comment) would need to be implemented.

@rnestler are you still interested in implementing those changes, or should we close the PR for now so somebody else can take over?

[rnestler]

@rnestler are you still interested in implementing those changes, or should we close the PR for now so somebody else can take over?

This PR is probably the wrong place to implement this anyways. So let's close it and me or somebody else may open a new one.

[dbrgn]

Opened an issue at #90.