feat(core): improve PathExt::replace_env and use it throught the codebase

[amrbashir]

This new implementation allows for expanding any environment variable so it is not limited to just ~, $HOME, $Env:USERPROFILE and $Env:KOMOREBI_CONFIG_HOME.

It expands the follwing formats:

• CMD: %variable%
• PowerShell: $Env:variable
• Bash: $variable.

Why?

Just for convenience, for example instead of $HOME/AppData/Roaming/applications.json, it can be $APPDATA/applications.json

Remaining questions?

• Should resolve_home_path function be removed? It is not just a wrapper around the new trait.
• Should ExpandEnvVars::expand_vars return a result when a variable doesn't exit in env or keep the path as is (current behavior)?

[CtByte]

I have added this a while back.

My ambition in #1245 was to replace all sorts of path shortcuts in one place. Do you think it could be used?

I would not mind if you remove my extension, just so it all could be in one place

[amrbashir]

Apologies, I totally didn't see that trait, I should've dug deeper 🙏 .

I think the implementation should be in PathExt as you originally did, However my implementation operates on OsStr instead of lossely converting into a String which could be problematic in some rare cases.

I think I will just move the implementation and tests there.

Is there a reason why your trait was not used instead of resolve_home_path function?

[LGUG2Z]

The long term goal is definitely to make sure what can do what PathExt is doing everywhere we read a Path-like string in every workspace crate - let's target this for v0.1.36 🤞

[CtByte]

Apologies, I totally didn't see that trait, I should've dug deeper 🙏 .

I think the implementation should be in PathExt as you originally did, However my implementation operates on OsStr instead of lossely converting into a String which could be problematic in some rare cases.

I think I will just move the implementation and tests there.

Is there a reason why your trait was not used instead of resolve_home_path function?

I basically only wanted to fix that issue linked in my PR, so I did not want to change everything. I did not forget about it but seems like someone else had the same idea with the paths 😉

Thank you for this PR!

[LGUG2Z]

@amrbashir Can we use this PR to unify the handling across all workspace crates?

[amrbashir]

yeah definitely, I will get on it

[amrbashir]

@LGUG2Z this should be ready, I searched throughout the code base for path and migrate any code that might need to PathExt::replace_env.

It is possible that I might have missed a few places due to my unfamiliarity with the code base, so if you find any, please let me know.

Most of the paths that needed this trait, are in:

1. Clap arguments, and that was handled by #[value_parse] attribute and a helper function.
2. SocketMessage and that was handled by custom deserialization with the help of serde_with crate

That said, I would appreciate a second eye and some extra testing.