feat: unmanaged installs #1410
feat: unmanaged installs #1410
Conversation
|
q: does this still attempt receipt creation? i think it'd be best to just not try at all |
|
The issue sort of identified a conflict between the two user groups this attempts to serve - one would care about receipts, the other is neutral on them. I tried to split the difference by attempting receipt creation, but treating receipt creation failure as harmless. |
|
hrm, i think splitting the difference here is maybe the less good option and we should consider 2 modes |
|
part of the reason i say this is that an unmanaged install is desirable for ephemeral environments which are usually automated- receipt creation is an i/o operation and while not particularly expensive it's not free- this feature in my mind is specifically for the "conductor" persona and they are the type that care about milliseconds |
mistydemeo
force-pushed
the
ci-mode
branch
5 times, most recently
from
1599949
to
d68b4fc
Compare
|
Based on our previous discussion, I've made a few changes:
- "install_dir_env_var": "CARGO_DIST_SCHEMA_INSTALL_DIR",
+ "environment_variables": {
+ "install_dir_env_var": "CARGO_DIST_SCHEMA_INSTALL_DIR",
+ "unmanaged_dir_env_var": "CARGO_DIST_SCHEMA_UNMANAGED_INSTALL",
+ "disable_update_env_var": "CARGO_DIST_SCHEMA_DISABLE_UPDATE"
+ }, |
|
we could probably name that |
|
Sounds good, done. - "environment_variables": {
+ "env": { |
| let env_app_name = name.to_ascii_uppercase().replace('-', "_"); | ||
| let install_dir_env_var = format!("{env_app_name}_INSTALL_DIR"); | ||
| let unmanaged_dir_env_var = format!("{env_app_name}_UNMANAGED_INSTALL"); | ||
| let disable_update_env_var = format!("{env_app_name}_DISABLE_UPDATE"); |
There was a problem hiding this comment.
my thought here was that the user cares about the "update" behavior. there is not always an "updater" so "update" focused on the behavior the user understands, not the impl
| let install_dir_env_var = format!("{env_app_name}_INSTALL_DIR"); | ||
| let unmanaged_dir_env_var = format!("{env_app_name}_UNMANAGED_INSTALL"); | ||
| let disable_update_env_var = format!("{env_app_name}_DISABLE_UPDATE"); | ||
|
|
There was a problem hiding this comment.
We should maybe also expose FLAT_INSTALL_LAYOUT as a raw option too? less certain of that
There was a problem hiding this comment.
i would agree with this, in all my conversations with folks it's not clear that flat or not flat is preferred
There was a problem hiding this comment.
How about we circle back around to publicizing this around the time we also give developers full control over the install layout?
| say "this installation will not be able to self-update" | ||
| local _retval=0 | ||
| else | ||
| err "unable to create receipt directory at $RECEIPT_HOME" |
There was a problem hiding this comment.
I'm happy to change it, but FWIW this is the text we already used before this PR. This isn't new, it just moved within the diff.
mistydemeo
force-pushed
the
ci-mode
branch
2 times, most recently
from
af29bcb
to
20f4c94
Compare
The new "unmanaged" installation mode allows for something close to "untar and move on" installations. It disables modifying the PATH and creation of environment files, and ensures all files are installed into a single flat directory no matter what other configuration is in place. It also disables installing a standalone updater and the creation of an install receipt. The new "don't install an updater/receipt" behaviour is also controllable behind a new public environment variable, $APPNAME_DISABLE_UPDATE. Fixes #1400.
| if ($unmanaged_install) { | ||
| $NoModifyPath = $true | ||
| $install_updater = $false | ||
| } |
There was a problem hiding this comment.
I think the "mode" variable should get applied first, and then the other overrides should kick in..?
| if [ -n "${UNMANAGED_INSTALL}" ]; then | ||
| NO_MODIFY_PATH=1 | ||
| INSTALL_UPDATER=0 | ||
| fi |
There was a problem hiding this comment.
ditto on mode should go first..?
There was a problem hiding this comment.
Honestly I think "unmanaged mode" is opinionated enough that it probably should override the individual options instead of the other way around. I see the individual options as being useful in normal mode, not for this.
|
I just realized that the shell installer does provide a CLI param for |
The new "unmanaged" installation mode allows for something close to "untar and move on" installations. It disables modifying the
PATHand creation of environment files, and ensures all files are installed into a single flat directory no matter what other configuration is in place. It also disables installing a standalone updater and the creation of an install receipt.The new "don't install an updater/receipt" behaviour is also controllable behind a new public environment variable,
$APPNAME_DISABLE_UPDATE.Fixes #1400.