EFForg
Use a non-example config file, if it exists
What problem does this feature solve or what does it enhance?
Right now the deploy code uses config.toml.example, which is checked into git. If you want to make changes to the config while developing you have to either modify the example file or the deploy code, and then be careful not to commit those changes to git.
Proposed Solution
The deploy code should probably use config.toml if it exists, falling back to config.toml.example if it doesn't. Then config.toml can be added to .gitignore.
Alternatives Considered
The defaults could also be added to config.rs, and then config.toml.example could be ignored by the code, which is probably more "correct". But then the defaults in code would need to be kept in sync with the example config.
This should be simple enough I'll try to submit a pull request in the next few days if nobody objects.
yes please. however i'd also add --reset-config flag that forcibly overwrites it.
What program would that be an argument to? I think the installer is already overwriting the version on the devices every time, but I assume you mean a flag to replace config.toml with config.toml.example?
oh nevermind. i didn't read your proposal carefully. i was thinking of something else.
with #351 there will be a way to change the config graphically. in that scenario i would like the installer not to overwrite the existing config on the device either. so we'd need to change the installer for that too.
i think what you propose is fine adding too.
we should probably just have a installer update orbic and installer update tplink command that just updates and skips all the rooting steps and also doesn't upload a new config.toml file, but the question then becomes how we handle config changes.
I think we can have ./installer orbic --keep-config and ./installer tplink --keep-config and it just skips that one file copy. i would like to still overwrite the config by default just so that users have a way to un-break their config if it is corrupted.
analogously we can have ./installer orbic --config-file=myconfig.toml -- might be a bit more explicit than discovering the config.toml in cwd and silently using that. wdyt
I think we should have an update argument too though that skips all the rooting stuff which is not necessary for just an update.
my concern is that we have multiple flows that are drifting apart, for unclear benefit (install speed? we can probably make the installer faster in a bunch of ways...)
my concern is that we have multiple flows that are drifting apart, for unclear benefit (install speed? we can probably make the installer faster in a bunch of ways...)
You mean for each device? I'm not sure how we get around that.
@gaykitty no, i mean having a separate install flow for "first install" vs "upgrade". I think it'd just be more fragmentation..
Since rayhunter will generate a default config if one isn't present, do we even need the installer to load a default config?
The new ability to set config though the web interface is great! I searched though issues before filing this but not PRs.
I'm assuming the web config editing is meant more for user-focused settings than developer focused ones, and that's why e.g. the dummy analyzer isn't there?
yeah, there was some discussion on the pr and it seemed like a footgun to put it there. the port setting too, because then we'd have to handle redirecting to the new page from the UI.
I still think an --upgrade option to the installer that skips rooting and skips uploading the config file is the best solution here
@simonft You offered to work on this: If you'd like to add in an --upgrade option to the installer, go for it!
OK great. I'll hopefully be able to do some work on this in the coming week.
Well, "coming week" was optimistic. I think I'm going to wait until #542 settles to move forward on this, since the two sets of changes will probably bump into each other and this one is probably going to be a lot simpler with an abstraction over the device installers.