ryanmelt
commented
1 year ago I considered doing this originally. The biggest problem happens if the gem is a tool or custom widget, because our runtime containers don't contain a full node environment, and generally won't have all the various node packages that you need included.
Would be easy for pure ruby plugins though.
First check out our main documentation site at https://openc3.com.
Is your feature request related to a problem? Please describe. The impact of this feature would help in a few cases:
There are a few less technically inclined users that have a blocker to upgrade from v4.5 to v5 due to not totally understanding the .gem build/upload process. It is not ideal that they would have server access locally but this would be useful in a development sense and less about production.
Describe the solution you'd like The local mode currently is able to sync portions of the repository in order to locally edit scripts and screens but not specifically edit the database or the complete configuration (conversion scripts, interface, etc...). The admin->plugins section already has a "upgrade plugin" button. It looks for the user to local a .gem file locally to have it upload/reinstall the plugin. With local_mode=1 in the .env, could that "upgrade plugin" button instead assume that the user has made a change to the ./plugins/DEFAULT/ directory and it would build the gem from that directory and then install the files. Building the gem may be an unnecessary step since loading the gem likely "unzips" the gem and then runs the config parsing/loading steps.
Additional context I am not totally savvy in what triggers or stands in the way of the local mode being able to reload the entire gem. Hoping that if its triggered by the user with the "upgrade plugin" button would maybe overcome the blockers for this feature.