The stage apply subcommand is a no-op if the pallet doesn't provide any Docker Compose apps and there are no scripts which would run as hooks for stage apply (e.g. to unmount+remount any overlays, reload the systemd daemon, etc). If the stage apply subcommand would be a no-op, then we should not suggest running it in the stdout "to apply this pallet immediately, run forklift stage apply" success message upon completion of the [dev] plt stage or stage set-next subcommands - such an instruction would be misleading, because the user would run it and expect a change which will not happen. Whenever a pallet exports files, we also should be sure to include some "you may need to restart your computer before you see all changes" text too (and if a pallet doesn't export files, we should suppress that text).
The
stage applysubcommand is a no-op if the pallet doesn't provide any Docker Compose apps and there are no scripts which would run as hooks forstage apply(e.g. to unmount+remount any overlays, reload the systemd daemon, etc). If thestage applysubcommand would be a no-op, then we should not suggest running it in the stdout "to apply this pallet immediately, runforklift stage apply" success message upon completion of the[dev] plt stageorstage set-nextsubcommands - such an instruction would be misleading, because the user would run it and expect a change which will not happen. Whenever a pallet exports files, we also should be sure to include some "you may need to restart your computer before you see all changes" text too (and if a pallet doesn't export files, we should suppress that text).