Closed pronebird closed 1 week ago
Using files section makes it possible to bundle external binaries and their resources under individual folders. External binaries setting does not provide such flexibility.
The resources
feature does though (the docs still weren't updated but it accepts objects to configure source and target paths). Doesn't really matter since i agree with you that it makes sense to add this for the sake of cross platform consitency, but still wanted to mention it x)
Using files section makes it possible to bundle external binaries and their resources under individual folders. External binaries setting does not provide such flexibility.
The
resources
feature does though (the docs still weren't updated but it accepts objects to configure source and target paths). Doesn't really matter since i agree with you that it makes sense to add this for the sake of cross platform consitency, but still wanted to mention it x)
That's good to know. However resources
are located at the bundle
level. Given that I use one tauri.conf.json
for all platforms, all assets specified under resources
would end up in each installer that I build.
Right now I am using resources
to bundle assets that are used on all platforms, macOS > files
to ship third-party binaries and their assets for macOS. That trick didn't work on windows.
Even if windows > nsis > files
were allowed, I'd still need a way to run custom pre-install and post-install scripts which in my case set-up windows service on Windows, or launch daemon on macOS. So for the time being, I had to resort to to the custom installer.nsi
. The tauri installer.nsi
template is 800 LOC long and if I could only tap into some parts of it without copying the whole thing, that would make it so much easier to build the installer.
That's good to know. However resources are located at the bundle level. Given that I use one tauri.conf.json for all platforms, all assets specified under resources would end up in each installer that I build.
Right now I am using resources to bundle assets that are used on all platforms, macOS > files to ship third-party binaries and their assets for macOS. That trick didn't work on windows.
You can have OS specific configs (that overwrite the main config) -> https://tauri.app/v1/api/config#platform-specific-configuration
Even if windows > nsis > files were allowed, I'd still need a way to run custom pre-install and post-install scripts which in my case set-up windows service on Windows, or launch daemon on macOS. So for the time being, I had to resort to to the custom installer.nsi. The tauri installer.nsi template is 800 LOC long and if I could only tap into some parts of it without copying the whole thing, that would make it so much easier to build the installer.
I did not disagree with the "Further thoughs" section of your PR description, i just think it's off-topic with this PR and should have its own issue/PR :)
That's good to know. However resources are located at the bundle level. Given that I use one tauri.conf.json for all platforms, all assets specified under resources would end up in each installer that I build.
Right now I am using resources to bundle assets that are used on all platforms, macOS > files to ship third-party binaries and their assets for macOS. That trick didn't work on windows.
You can have OS specific configs (that overwrite the main config) -> https://tauri.app/v1/api/config#platform-specific-configuration
Even if windows > nsis > files were allowed, I'd still need a way to run custom pre-install and post-install scripts which in my case set-up windows service on Windows, or launch daemon on macOS. So for the time being, I had to resort to to the custom installer.nsi. The tauri installer.nsi template is 800 LOC long and if I could only tap into some parts of it without copying the whole thing, that would make it so much easier to build the installer.
I did not disagree with the "Further thoughs" section of your PR description, i just think it's off-topic with this PR and should have its own issue/PR :)
Thanks again. The merged config could work in my case, at least I wouldn't have to copy files manually.
Since it's not documented how to write the resources map, could you please maybe shed some light on how does one specify the glob pattern in map, i.e should it be this:
"resources": {
"tray-icons/": "tray-icons/*.png",
}
or that?
"resources": {
"tray-icons/*.png": "tray-icons/*.png",
}
I'll make sure to create another issue in regards of nsis installer hooks.
Update: it seems that resource map works different from files
, for example if I want to bundle a binary from target/release
folder, the bundler errors, stating that the file already exists, which tells me that it must be copying files.
Maybe that's because when building a universal mac binary, my workspace binaries aren't compiled into universal-apple-darwin
folder and so the copying mechanism works fine, but on Windows everything falls into target/release
.
If I got it right, the syntax is inverted here, i.e key is path to file, value is where to put it in installer. Keys and values are flipped in that sense in macos > files
"resources": {
"../../target/release/my-other-bin.exe": "my-other-bin.exe"
}
I'll create an issue for that too 😓
I see no reason to include this option, as your use-case is already covered by resources
map and the other files
option (.deb
for example) is to copy files into subdirectories within the .deb
file not the final install location. It also doesn't have any APIs to resolve access to them.
This PR adds support for
files
for NSIS installer, similar setting can be found undermacOS
configuration. The rationale for adding this is the following:files
section makes it possible to bundle external binaries and their resources under individual folders. External binaries setting does not provide such flexibility.Further thoughts
Making custom
installer.nsi
is difficult. It would be better to provide a way to have a pre and post install hooks. Maybe we could include custom.nsh
files that would augment the behavior oftemplates/installer.nsi
.This is still work in progress and I am not able to test it. Somehow I keep stumbling upon the following error which is a dead end given that it does mention the source of this error:
Closes https://github.com/tauri-apps/tauri/issues/9652