Less statics

[sftse]

Work on refactoring the globals in tauri-cli. I think this is beneficial as-is, but it is not quite finished.

This still is missing a full transition towards lazy initialized tauri_dir and frontend_dir while guaranteeing not to break anything, as discussed in this comment.
Completed.

Read commit-by-commit.

[github-actions]

Package Changes Through 1ee20a9

There are 8 changes which include tauri-utils with patch, tauri-build with patch, tauri-cli with patch, tauri-macos-sign with patch, @tauri-apps/cli with patch, tauri-runtime-wry with minor, tauri-runtime with minor, tauri with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tauri-utils	2.8.1	2.8.2
tauri-macos-sign	2.3.2	2.3.3
tauri-bundler	2.7.5	2.7.6
tauri-runtime	2.9.2	2.10.0
tauri-runtime-wry	2.9.3	2.10.0
tauri-codegen	2.5.2	2.5.3
tauri-macros	2.5.2	2.5.3
tauri-plugin	2.5.2	2.5.3
tauri-build	2.5.3	2.5.4
tauri	2.9.5	2.10.0
@tauri-apps/cli	2.9.6	2.9.7
tauri-cli	2.9.6	2.9.7

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[sftse]

Any chance to run CI automatically on my PRs? Would make iteration much faster, I often miss things built only on other platforms.

[FabianLars]

Any chance to run CI automatically on my PRs? Would make iteration much faster, I often miss things built only on other platforms.

That decision will probably take longer to discuss than your pr will be open x)

[sftse]

This is RFR

[sftse]

@FabianLars
I put effort into readable commits that compile individually. High-latency round trips reduce the quality of my contributions, here the last commits merge multiple unrelated things because it takes way too long to figure out what is related.

RFR

[sftse]

Fixed next errors

[FabianLars]

I put effort into readable commits that compile individually. High-latency round trips reduce the quality of my contributions, here the last commits merge multiple unrelated things because it takes way too long to figure out what is related.

Yeah i totally get that. GitHub only offers us 2 options: Auto run workflows for everyone or only for those with write permissions. There's no way to give individuals workflow permissions without also giving write access to the repo. All in all very annoying.

You could however enable workflow runs in your own fork (free of charge since it's open source) and open a second PR from your branch against your own fork's dev branch.

[sftse]

You could however enable workflow runs in your own fork (free of charge since it's open source) and open a second PR from your branch against your own fork's dev branch.

Didn't think of that, I'm not familiar with the workflows.
I might take that for a spin, thanks.

[FabianLars]

whoops sorry, didn't mean to click on button...

[sftse]

To add more context to this PR, it's a bit tersely described, there is an overuse of statics in the code base which lead to verbose code patterns like Mutex<Option<ConfigMetadata>> or OnceLock<Mutex<ConfigMetadata>> to initialize the config in the static. This is better solved with locals, and in most cases successfully removes both the Mutex and the Option, replacing it with just ConfigMetadata. Leaning more heavily into borrowing reduces the chance for deadlocks.

In quantitative terms, this change removes 43% (76/178) of all unwraps in the tauri-cli crate.
It might be possible to remove all statics and further reduce the scope where Mutexes are used, but that's how far I got.

[sftse]

Fixed CI

[Legend-Master]

Sorry about the late reply. I am a bit skeptical about this change since this means we now need to pass those arguments all the way down

The dependency is much more clear though, but I honestly wonder if that really makes a difference if we always initialize the config and directories at he beginning of a command

[sftse]

I don't disagree that the amount of arguments passed to some functions is starting to get unwieldy. I think we can do something about it by redrawing the function boundaries but this PR had to make a judgement call whether to stop at a point where it is still reasonably obvious that the behavior hasn't changed or to continue with less conservative changes.

but I honestly wonder if that really makes a difference if we always initialize the config and directories at he beginning of a command

We actually don't, see the resolve command in info/mod.rs wrapped in an if block. Not that I'd have been able to guess it from just reading the code, but that block is always useless since the path is never read from the global after that. The config too is initialized in a more different way than the other commands.

I think the code is much more defensive this way, apart from the substantial reduction of unwraps, it also increases the confidence there are no deadlocks. The pattern of having a mutex in a static is always a bit dangerous, because it can always be accessed and locked from anywhere, and it isn't clear if it has been locked in a parent scope. If we refactor to remove the locks it is a static proof we don't have any deadlocks. Other mutexes that are not in a static coupled with callbacks already led to deadlocks before, see #14694

[Legend-Master]

I am much more convinced now, thanks for the explanation

Looking back, I had quite a few times struggling to understand where is a function looking the directories from, this is definitely a good improvement

[Legend-Master]

Looks good from an initial look

My monitor's in repair right now and it's really difficult for me to look at the huge diffs, so this may need to wait until then

Also cc @FabianLars @lucasfernog what you guys think of about this change?

[Legend-Master]

After looking at the code more closely, this is definitely a great improvement to readability, awesome work!

So happy my monitor's finally back today 😁

[sftse]

As always, thanks for taking the time to review my PRs, much appreciated.

More coming up soon..