fix(tauri-plugin): do not modify src

[Flakebi]

Write temporary permission files to out_dir instead of current directory. The current directory is the source directory and it should not be modified by the build.

Fixes #11187

[github-actions]

Package Changes Through 7525e6c

There are 8 changes which include tauri-bundler with minor, tauri-cli with minor, tauri-codegen with minor, tauri-utils with minor, @tauri-apps/cli with minor, tauri with minor, @tauri-apps/api with minor, tauri-runtime-wry with patch

Planned Package Versions

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

package	current	next
@tauri-apps/api	2.5.0	2.6.0
tauri-utils	2.4.0	2.5.0
tauri-bundler	2.4.0	2.5.0
tauri-runtime	2.6.0	2.6.1
tauri-runtime-wry	2.6.0	2.6.1
tauri-codegen	2.2.0	2.3.0
tauri-macros	2.2.0	2.2.1
tauri-plugin	2.2.0	2.2.1
tauri-build	2.2.0	2.2.1
tauri	2.5.1	2.6.0
@tauri-apps/cli	2.5.0	2.6.0
tauri-cli	2.5.0	2.6.0

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

---

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

[Legend-Master]

I honestly get this is a bad practice but I don't have a good idea about how to fix it

I am thinking, maybe we can put the schema and command permission auto gen behind a feature flag, and let people enable it through dev-dependencies so that it's only used in dev, this should somewhat mitigate the problem, but honestly, there're many more places where we modify things outside of OUT_DIR that are kinda necessary, so I don't know how much would it help

[Legend-Master]

We have 2 types of permissions, the auto generated ones from the commands (e.g. in your build script, you defined a command ping, it will generate allow-ping and deny ping), and the ones you write yourself, we will need to keep this path

https://tauri.app/develop/plugins/#permission-files

[Legend-Master]

The schema are there to help you write your own permissions, putting it the OUT_DIR makes it impossible to use since the location of it is not fixed

[FabianLars]

i also wasn't involved in most things that write into src-tauri instead of out_dir but in other places we later changed the logic to first check if the content actually changed before writing to disk, would that help for the linked issue?

[WSH032]

but honestly, there're many more places where we modify things outside of OUT_DIR that are kinda necessary, so I don't know how much would it help

I would say that it is necessary for tauri_plugin.

I have a crate that depends on tauri-plugin-notification. Since docs.rs is a read-only environment, upgrading tauri_plugin from 2.0.3 to 2.2.0 caused my documentation build to fail.

I'm not sure if I'm correct, but I think the only things being modified outside of OUT_DIR are src-tauri/capabilities/ and the plugin crate's /permissions directory.

For src-tauri/capabilities/, since it's part of your own project, this usually isn't a problem.
However, for /permissions, because it's not part of your project (e.g., /opt/rustwide/cargo-home/registry/index.crates.io-xxx/tauri-plugin-xxx/), you have no control over its write permissions. So at least, we should ensure that /permissions is not being modified.

but in other places we later changed the logic to first check if the content actually changed before writing to disk, would that help for the linked issue

I think that could help? at least in resolving the issue on docs.rs, since plugin crates used as dependencies shouldn't be modifying their /permissions directory.

---

BTW, is it possible to resolve this issue soon? Or would Tauri be okay with me temporarily mitigating the error on docs.rs in this way?
Right now the all of pytauri documentation is broken 😂.

[Legend-Master]

Seems like the error was that it's trying to write the schema, I'm not sure why though since we do publish the schemas as well as having write_if_changed checks on it

I'm not sure if I'm correct, but I think the only things being modified outside of OUT_DIR are src-tauri/capabilities/ and the plugin crate's /permissions directory.

I recently discovered that the android build script will put tauri's android files to plugin's android folder (which I don't understand why), I'm not entirely sure how many more things are not written to the OUT_DIR though

[Flakebi]

Thanks for the quick review.
I looked some more into this and it looks like the problem is that (for me) the permission schema that is generated for tauri-plugin-notification is slightly different from the one on crates.io (e.g. changes in comments).
So, it seems like this could be fixed by updating tauri-plugin-notification but that seems rather brittle.

I changed this patch to instead rely on $CARGO_PRIMARY_PACKAGE, which is set when a package is built as the main target and not set for dependencies. This should yield the wanted outcome that the files are auto-generated in the src directory when developing a plugin, but not when using a plugin as a dependency.

[WSH032]

According to tauri-apps/plugins-workspace#2771 (comment), I suspect that the versions of tauri-plugin (or dependencies like jsonschema used to generate permissions) required by plugins-workspace and by users (during local development or on docs.rs) are different at build time.

This explains why updating permissions is not needed when developing inside plugins-workspace, but is required in user environments and on docs.rs. Based on this idea, simply updating tauri-plugin-notification is not enough, because users can specify an older version of tauri-plugin, which would still require updating (downgrading) permissions.

Using $CARGO_PRIMARY_PACKAGE is a good idea, because published dependencies really shouldn't modify their source folders during build (cargo will warn you unless you use --allow-dirty). However, this is somewhat of a BREAKING CHANGE, as it changes plugin developers' habits (they might not track their permissions in git). But, I support this change, as it is best practice for plugin development (i.e., don't use --allow-dirty). I just think we should mention this in the documentation.

Finally, regarding this PR, why don't we apply $CARGO_PRIMARY_PACKAGE to the entire Builder::try_build?

[Legend-Master]

However, this is somewhat of a BREAKING CHANGE, as it changes plugin developers' habits (they might not track their permissions in git)

I think it should still work the same as before for publishing libraries since they would be the primary package in that case right? Oh I see what you mean, if they didn't publish those files before, that would be a problem

I just think we should mention this in the documentation.

This is true though

Finally, regarding this PR, why don't we apply $CARGO_PRIMARY_PACKAGE to the entire Builder::try_build?

That wouldn't work, there're a lot more stuffs going on than just generating permission files (e.g. telling tauri-build about the global api scripts)

[Legend-Master]

We'll also need to guard generate_docs, autogenerate_command_permissions calls, basically, anything that would potentially change things outside of OUT_DIR

And as @WSH032 mentioned, this might be a breaking change if the plugin author didn't ship the automatically generated permission files before, so maybe we need to push the output of autogenerate_command_permissions to define_permissions as well (honestly I feel like we might need some reworks around this but I don't have much ideas about how right now)

[WSH032]

there're a lot more stuffs going on than just generating permission files (e.g. telling tauri-build about the global api scripts)

I have to say, this is a bit confusing 🤐—if you're not familiar enough with Tauri, it's hard to figure out all the places that need to be handled.

this might be a breaking change if the plugin author didn't ship the automatically generated permission files before, so maybe we need to push the output of autogenerate_command_permissions to define_permissions as well (honestly I feel like we might need some reworks around this but I don't have much ideas about how right now)

Personally, I don't think we should continue supporting this use case. In my opinion, the drawbacks far outweigh the benefits of semantic compatibility. (You'll get rejected by cargo publish, can't do reproducible builds, and can't be built as a dependency on docs.rs.)

When I mentioned breaking change, I just meant we should update the documentation accordingly. In fact, even if we don't make this breaking change, we should still recommend in the docs that users track their permissions files—otherwise, they'll run into issues the first time they publish.

[Legend-Master]

I have to say, this is a bit confusing 🤐—if you're not familiar enough with Tauri, it's hard to figure out all the places that need to be handled.

Indeed, this part of tauri is quite hard to follow

Personally, I don't think we should continue supporting this use case. In my opinion, the drawbacks far outweigh the benefits of semantic compatibility. (You'll get rejected by cargo publish, can't do reproducible builds, and can't be built as a dependency on docs.rs.)

I'm fine with either ways, don't mind the breaking either to be honest, also looking at the plugins at https://github.com/tauri-apps/awesome-tauri?tab=readme-ov-file#plugins, it seems like people do commit them in (probably because of the plugin template)

I think for now, just guarding these parts with std::env::var("CARGO_PRIMARY_PACKAGE").is_ok() check should be a good start

tauri/crates/tauri-plugin/src/build/mod.rs

Lines 114 to 116 in 2212547

	if !self.commands.is_empty() {
	acl::build::autogenerate_command_permissions(&commands_dir, self.commands, "", true);
	}

tauri/crates/tauri-plugin/src/build/mod.rs

Lines 122 to 136 in 2212547

	if permissions.is_empty() {
	let _ = std::fs::remove_file(format!(
	"./permissions/{}/{}",
	acl::PERMISSION_SCHEMAS_FOLDER_NAME,
	acl::PERMISSION_SCHEMA_FILE_NAME
	));
	let _ = std::fs::remove_file(autogenerated.join(acl::build::PERMISSION_DOCS_FILE_NAME));
	} else {
	acl::schema::generate_permissions_schema(&permissions, "./permissions")?;
	acl::build::generate_docs(
	&permissions,
	&autogenerated,
	name.strip_prefix("tauri-plugin-").unwrap_or(&name),
	)?;
	}