config impl (pt.1) #1550

Sk7Str1p3 · 2025-03-28T19:58:39Z

Goals

Implements advanced customisation with config file in toml format. This pull request (pt.1) aims to implement just basic configuration, and pt.2 will go much deeper with it.
Resolves #745

Todo

Target	Progress
Allow user define existing cli opts in config file	setup config parser create basic config structure override config parametrs with values from CLI
Implement new cli/config options	modules order (requires major changes in logic) custom functions
Advanced	per-language configuration (ascii/pic logo, color, etc..) per-project (see Config file for theming/customization💄 #745 (comment))

upd: i doubt functions 'custom' are really necessary

Sk7Str1p3 · 2025-03-28T20:01:41Z

@spenserblack I'm sorry for pinging you that many times... I opened new PR

Current problem is config is not spawning at $XDG_CONFIG_HOME, but it spawns folder. I am not able to check how does config parsed because is not created. Waiting for your answer, thx

spenserblack · 2025-03-28T20:42:30Z

I'm sorry for pinging you that many times

No worries.

I am not able to check how does config parsed because is not created.

Since you're using serde, you should be able to read the config from a string. Or a reader type that uses a string. I'd honestly use that for testing. You can use include_str!("path/to/test-config.toml"), load the configuration from the TOML string, and test its values.

Since the CLI type implements Parser, you can also test the CLI by passing one of the iterator types (simplest being an array of strings) to .try_parse_from, which will then let you test how the CLI and config resolve together.

I'd recommend putting the tests and test config file into tests/ to organize things, because we probably don't want random .toml files in the source code.

spenserblack

See review comment. I think it should help you figure out why the config file isn't being created.

src/config.rs

Sk7Str1p3 · 2025-03-29T14:19:47Z

i think i should write a todo with what are my plans on customisation with config

config sample:

separator = " -> "
number-separator = comma

# this should support custom ascii and images
# if images not supported will fallback to custom ascii if provided and standard if not
[logo] 
ruby = ./ruby.png
c = ./c.txt
rust = { image = ./rust.png, ascii = ./rust.txt }

# like --disabled-field, but lets you change order
modules = """
  name
  break

  project
  created
  authors
  break

  head
  last-change
  pending
  churn
  lines-of-code
  break

  size
"""

# detailed settings on module
[name]
format = -----$name|$version-----

Sk7Str1p3 · 2025-03-29T20:12:41Z

Nah, we won't get any good customization if we just parse config as CLI arguments. I reverted all commits

I am looking forward to CrabFetch approach. All customisation made by configuration file, and CLI just lets you some minimal settings.
We can also do things like FastFetch does. It has enormous amount of CLI arguments and uses values in config as arguments. I do NOT like that.

@spenserblack what's your opinion on that?

spenserblack · 2025-03-31T12:24:42Z

Nah, we won't get any good customization if we just parse config as CLI arguments.

Could you explain this a bit more? You hint at overriding logos per-language in #1550 (comment), which wouldn't work if config and CLI are identical. Is that the main issue, or are there others?

I am looking forward to CrabFetch approach. All customisation made by configuration file, and CLI just lets you some minimal settings.
We can also do things like FastFetch does. It has enormous amount of CLI arguments and uses values in config as arguments. I do NOT like that.

Each repository is different, and can require different options. For example, if a repository has a logo, show that with -i. In many repositories, the user would want to use -T to get stats that better represent the "real" dominant language. Frankly, if I had to write a config file to set these, a config file that I may never use again (likely if I'm not a maintainer of the repo I'm analyzing), I would find it a bit annoying. IMO, simply allowing users to store and not repeat some CLI arguments is a big win. But I'm still of the opinion that the design should be CLI first, config file secondary.

spenserblack · 2025-03-31T12:33:17Z

OK, I've just reread the idea that was documented in #745. I had kind of forgotten the original intent of that issue 😅

I've noticed that the original issue body was mainly focusing on display configuration options. This makes sense to me, since those are the types of things that I'd likely only want to set once, not per-repo. Also, some options would be kind of awkward to set via the CLI, like if I was trying to set Nerd Font icons for the info lines.

So, yeah, I'm backtracking on the config file being a 1:1 with the CLI. Instead, we should focus on a limited set of options that we're very confident would only be set once, regardless of repo. And also some options that may work best in a config file instead of as CLI arguments.

@o2sh Thoughts?

Sk7Str1p3 · 2025-03-31T15:26:21Z

Instead, we should focus on a limited set of options that we're very confident would only be set once, regardless of repo

Those could be key-value separator, number separator, nerd-fonts switch and natural colors (use colors set by terminal) switch (to be implemented).

Im working on those and possibly finish in just few hours.

Sk7Str1p3 · 2025-03-31T15:27:25Z

Speaking of key-value separator, check this out

This confusing me, why that would happen? Why I could not use -> as separator?

spenserblack · 2025-03-31T16:34:35Z

This confusing me, why that would happen? Why I could not use -> as separator?

That's going to be caused by clap, the library for argument parsing. It's reading the next argument after --separator and seeing ->. I believe from there it's checking that the next argument starts with - (it does), and interpreting that as another CLI switch/option instead of as the value passed for --separator.

There's perhaps an option that would force clap to take whatever argument is next, regardless of format.

Sk7Str1p3 · 2025-03-31T17:59:46Z

AYO I MADE BASE FOR CONFIG!!1!
currently slowly creating commits

Sk7Str1p3 · 2025-03-31T18:37:26Z

@spenserblack I got one annoying error with config file - values MUST be set there, otherwise onefetch is crashing

spenserblack · 2025-03-31T20:35:43Z

@spenserblack I got one annoying error with config file - values MUST be set there, otherwise onefetch is crashing

I think the easiest thing to do would be to just wrap them all in Option to make them nullable.

Also, ideally, let's not remove options from the CLI. Here's roughly how shared options should be resolved.

let opt = cli.opt.or(config.opt).unwrap_or(default_opt);

Check out the huge amount of helper methods defined on Option<T>.

Sk7Str1p3 · 2025-04-01T12:19:49Z

Also, ideally, let's not remove options from the CLI. Here's roughly how shared options should be resolved.

i dont really think someone would like to override such things like separators from CLI

by the way, check latest commit, i did wrap values on Option, but code seems kinda idiotic imo

Sk7Str1p3 · 2025-04-01T13:57:13Z

why does this freaky ':' appears?

Sk7Str1p3 · 2025-04-01T16:35:56Z

@spenserblack i could not really find why ":" is hardcoded as separator, do you have any ideas?

Sk7Str1p3 · 2025-05-04T16:19:25Z

It seems to compile, finally

Sk7Str1p3 · 2025-05-04T20:30:15Z

Lmfao it thinks config.toml is a directory. I forgot to use parent() method, I will fix tomorrow

Sk7Str1p3 · 2025-05-05T13:56:46Z

@spenserblack I experienced some troubles with writing config - the default path is EMPTY. I set it in default() for ConfigCliOptionsbut then i use unwrap_or_default(), path presents empty.
Second issue is that config is being overwritten, I thought fs::write would tell me if file exist

spenserblack · 2025-05-05T14:15:43Z

@spenserblack I experienced some troubles with writing config - the default path is EMPTY. I set it in default() for ConfigCliOptionsbut then i use unwrap_or_default(), path presents empty.
Second issue is that config is being overwritten, I thought fs::write would tell me if file exist

Yeah, you're going to have to combine it with dirs. The home/config directory is kind of an edge case, so it might be OK to have a panicking unwrap when dirs returns None

Sk7Str1p3 · 2025-05-05T17:37:14Z

hm @spenserblack something odd happens. it cant unwrap to default because the value is PRESENT, but it is an empty path. i cannot figure out the cause of this problem

spenserblack · 2025-05-05T17:53:54Z

src/config.rs

+        }
+    }
+
+    pub fn write_default<P>(path: P) -> Result<()>


If you refactor this to write(&self, path), then we can call ::default().write("path") instead. A bonus from this is that we're already set up to write other configs, for example if we needed to dump the config for debugging.

done;

i also think you found my commits chaotic and weird, i will recommit in more pretty way a bit later

spenserblack · 2025-05-05T17:56:35Z

hm @spenserblack something odd happens. it cant unwrap to default because the value is PRESENT, but it is an empty path. i cannot figure out the cause of this problem

🤔 I'll have to look into where that's happening, but Option::<T>::default() should always be Option::None.

spenserblack · 2025-05-05T18:01:42Z

src/main.rs

+    if cli_options.config.generate_config {
+        // what the actual FUCK is happening here?
+        // why default path is EMPTY?
+        return ConfigOptions::write_default(&cli_options.config.config_path.unwrap_or_default());


At, here it is, if I understand your problem correctly. Don't do .unwrap_or_default(), do .unwrap_or_else(|| dirs::config_path().expect("config path to exist").

Edit: actually, write(), rather than using expect(), you can return a Result::Err.

Option::<PathBuf>::unwrap_or_default() is equivalent to

let path_buf = match config_path { Some(p) => p, None => PathBuf::default(), };

I'm thinking you were expecting the default PathBuf as defined in your Default implementation, instead of the PathBuf::default().

exactly what i expected to get, is it supposed to work like that or it is a bug?

I'm pretty sure PathBuf::default() is supposed to return an empty PathBuf, if that's what you're asking.

No, I mean why does unwrap_or_defaultreturn PathBuf::default()and not ConfigCliOptions::default().config_path

Sk7Str1p3 · 2025-05-05T19:18:27Z

src/info/mod.rs

        Self {
            title: None,
            info_fields: Vec::new(),
+            // I have totally NO idea how to properly override values
+            // if cli_options.info.disabled_fields is NOT type of Option<T>


@spenserblack not sure if i should wrap all types into Option <T> as i suppose this would require major changes in code but i cant see another way to override values

Check out these docs for telling serde what the value should default to if it's not available: https://serde.rs/attr-default.html

That way you don't have to wrap everything in Option and manually unwrap to a default.

isn't this should be done with clap rather than serde? we are overriding config with cli, so rather clap should default to config value

Hm, yes, clap also provide default_value

Tested in last commit. Currently I got vectors concatenation instead of overwrite, and clap throws error if --disabled-fields is not set with CLI. I think wrap into Option would be better decision

Sk7Str1p3 · 2025-05-06T12:01:06Z

@spenserblack I tried to implement parameters override but without wrapping into Option this is near to impossible or at least much more complicated than it could be

This reverts commit c4fdd83.

Sk7Str1p3 · 2025-05-06T19:47:40Z

Yep as I expected, wrapping into Option is most convenient, logical, right way to override. Currently im trying to write a function which would look like

let disabled_fields = merge_with_cli(/* Value to merge */)
// or maybe CliOptions::merge?

Tho I also must decide whether to merge entire struct or just one value...

Anyway I'm on final stretch and this PR is going to be ready to get merged really soon

Sk7Str1p3 · 2025-05-07T19:12:58Z

@o2sh ready to merge (just will have to recommit in prettier way), and I would like to get some advices on my code

SirJiga

Nothing interesting

Sk7Str1p3 requested review from spenserblack and o2sh as code owners March 28, 2025 19:58

vercel bot deployed to Preview March 28, 2025 19:59 View deployment

spenserblack requested changes Mar 28, 2025

View reviewed changes

src/config.rs Outdated Show resolved Hide resolved

vercel bot deployed to Preview March 29, 2025 19:23 View deployment

vercel bot deployed to Preview March 29, 2025 20:05 View deployment

vercel bot deployed to Preview March 30, 2025 11:37 View deployment

Sk7Str1p3 force-pushed the main branch from a7d117b to 6b54870 Compare March 30, 2025 13:17

vercel bot deployed to Preview March 30, 2025 13:17 View deployment

Sk7Str1p3 changed the title ~~config impl~~ better customisation Mar 30, 2025

Sk7Str1p3 force-pushed the main branch from 6b54870 to 83d1d42 Compare March 31, 2025 14:23

vercel bot deployed to Preview March 31, 2025 14:23 View deployment

vercel bot deployed to Preview March 31, 2025 18:09 View deployment

vercel bot deployed to Preview March 31, 2025 18:30 View deployment

vercel bot deployed to Preview April 1, 2025 12:18 View deployment

fix paths

5c3fd59

vercel bot deployed to Preview May 5, 2025 13:51 View deployment

Merge branch 'main' into main

2c7d4f2

vercel bot deployed to Preview May 5, 2025 17:31 View deployment

spenserblack reviewed May 5, 2025

View reviewed changes

refactor to be able to write not only default

9f9f974

vercel bot deployed to Preview May 5, 2025 18:48 View deployment

Sk7Str1p3 commented May 5, 2025

View reviewed changes

interesting

c4fdd83

vercel bot deployed to Preview May 6, 2025 06:06 View deployment

Revert "interesting"

50e3720

This reverts commit c4fdd83.

Sk7Str1p3 added 2 commits May 7, 2025 17:01

test override

5e57cdc

almost last

81a9131

vercel bot deployed to Preview May 7, 2025 18:37 View deployment

Sk7Str1p3 requested a review from spenserblack May 7, 2025 19:07

Sk7Str1p3 marked this pull request as ready for review May 7, 2025 19:07

SirJiga reviewed May 7, 2025

View reviewed changes

Sk7Str1p3 added 2 commits May 8, 2025 19:25

update lock

a72018a

last one

4761134

vercel bot deployed to Preview May 8, 2025 19:32 View deployment

config impl (pt.1) #1550

Are you sure you want to change the base?

config impl (pt.1) #1550

Conversation

Sk7Str1p3 commented Mar 28, 2025 • edited Loading

Goals

Todo

Sk7Str1p3 commented Mar 28, 2025

spenserblack commented Mar 28, 2025

spenserblack left a comment

Choose a reason for hiding this comment

Sk7Str1p3 commented Mar 29, 2025 • edited Loading

Sk7Str1p3 commented Mar 29, 2025 • edited Loading

spenserblack commented Mar 31, 2025

spenserblack commented Mar 31, 2025 • edited Loading

Sk7Str1p3 commented Mar 31, 2025

Sk7Str1p3 commented Mar 31, 2025 • edited Loading

spenserblack commented Mar 31, 2025 • edited Loading

Sk7Str1p3 commented Mar 31, 2025

Sk7Str1p3 commented Mar 31, 2025

spenserblack commented Mar 31, 2025

Sk7Str1p3 commented Apr 1, 2025

Sk7Str1p3 commented Apr 1, 2025

Sk7Str1p3 commented Apr 1, 2025 • edited Loading

Sk7Str1p3 commented May 4, 2025

Sk7Str1p3 commented May 4, 2025

Sk7Str1p3 commented May 5, 2025

spenserblack commented May 5, 2025

Sk7Str1p3 commented May 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spenserblack commented May 5, 2025

spenserblack May 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sk7Str1p3 commented May 6, 2025

Sk7Str1p3 commented May 6, 2025 • edited Loading

Sk7Str1p3 commented May 7, 2025

SirJiga left a comment

Choose a reason for hiding this comment

Sk7Str1p3 commented Mar 28, 2025 •

edited

Loading

Sk7Str1p3 commented Mar 29, 2025 •

edited

Loading

Sk7Str1p3 commented Mar 29, 2025 •

edited

Loading

spenserblack commented Mar 31, 2025 •

edited

Loading

Sk7Str1p3 commented Mar 31, 2025 •

edited

Loading

spenserblack commented Mar 31, 2025 •

edited

Loading

Sk7Str1p3 commented Apr 1, 2025 •

edited

Loading

spenserblack May 5, 2025 •

edited

Loading

Sk7Str1p3 commented May 6, 2025 •

edited

Loading