You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Only applies to script installers (shell, powershell).
When install-path = "CARGO_HOME" was the only possible setting it didn't make sense to unpack anything but binaries, but other options like install-path = "~/.my-app" would be very reasonable to allow more verbose unpacking of things like READMEs/LICENSES.
The most simplistic design would just be unpack-all = true, but there's questions about overlaying old files/dirs (for updates) that might be worth being able to elaborate on.
Need someone to chime in with this as a requirement before I try to design the feature.
The text was updated successfully, but these errors were encountered:
I'm using cargo-dist in a project that expects a directory of config files (sample workflow definitions, needed to make the app very useful) to be installed along with the binary. The tarball includes these via include = ["./myapp_files/"], which is great.
I defined install-path = ["$MYAPP_HOME/", "~/.myapp"], expecting the extra dir to be unpacked as ~/.myapp/myapp_files. When that didn't work I discovered this issue, so I figured I'd let you know a real user has the use case described here.
The simplistic design sounds like it would work fine for me. If that would also extract README/LICENSE/etc then even better, I'd go ahead and include the docs/ dir too.
EDIT: Another option could be to define a separate location for these extra files to be extracted. That seems like it would retain compatibility w/CARGO_DIST for binaries, and if install-path is defined then maybe the same dir could also be used for the extra files. For system-wide installs this might make it easy to use /etc/myapp for configs.
Requiring the "extra files" target to be a different location than binaries would also work, in case that simplifies the implementation at all. In that case I would probably use:
EDIT 2 (apologies): ...now that I fully grok your concerns about old files, that does apply to my use case. The app is bundled with sample topologies that users are expected to extend. If their changes were lost after an upgrade, that might disappoint someone, although in my case the file location is an input when running the app, so it would be trivial to solve via documentation, and everything above still applies.
Only applies to script installers (shell, powershell).
When
install-path = "CARGO_HOME"
was the only possible setting it didn't make sense to unpack anything but binaries, but other options likeinstall-path = "~/.my-app"
would be very reasonable to allow more verbose unpacking of things like READMEs/LICENSES.The most simplistic design would just be
unpack-all = true
, but there's questions about overlaying old files/dirs (for updates) that might be worth being able to elaborate on.Need someone to chime in with this as a requirement before I try to design the feature.
The text was updated successfully, but these errors were encountered: