bartfeenstra / backuppy Goto Github PK

• Logging (#45)
• Catch uncaught exceptions, log them, and make the CLI output user-facing messages only. But what to do with important log messages if no logger has been configured? (#50)
• SSH sources (currently we have path sources only, and SSH for targets only)
• Allow verbosity to be overridden in the CLI (enabled/disabled) (#47)
• An init command to create a new configuration file, either as YAML (default, with comments) or JSON. Enable the stdio notifier by default, as well as sensible logging, and inform the user of how to consult the logs. (#51)
• Commands to convert JSON to YAML and back. Actually, probably not necessary, as this was intended so novices can convert examples, for instance, but with the new init command, which can output in JSON or YAML, I don't think we need dedicated conversion commands.
• A command to test the configuration. It will also try to check if all locations are available. If they aren't, then that should be debugging output, not an error, but it we must also ensure this lets users accept SSH host keys. Or, instead, we add a --dry-run or --simulate option to commands taking configuration? (postponed to 0.4.0: #46)

Can we simplify locations by requiring paths to be absolute? Then we can convert all other paths, if they are relative, to absolute ones in relation to these location paths.

A use case is adding file patterns (for rsync's --exclude= and --include=). rsync does not seem to resolve those against the source path if the patterns are relative.

The implementation would involve moving the paths from locations to the top-level configuration. We can simplify the configuration files' source and target settings by repurposing those to just take strings paths. A newly introduced source_type and target_type would default to path, and a newly introduced source_configuration and target_configuration would contain any optional location configuration.

For local path locations, the source and target values may be relative. They will be provided in absolute form by resolving them against the location of the configuration file being used.

HOWEVER, this all depends on the source and target paths not changing. I don't foresee any problems within the scope of the use cases envisioned for Backuppy, but it's something to keep in mind.

• A command to restore paths from the latest backup. Must ask for confirmation, because it overrides live/production data. Use -f or -y to override the confirmations and make the command non-interactive. (#53) (#56)
• Add --file and --dir arguments to the backup command, that will have the same effect as on the restore command. (#58)
• Publish API documentation. (#57)
• Bug #61
• SSH sources (#74)

What should we do with symlinks pointing to locations outside include directories? Can rsync handle this out of the box?

• A command to test the configuration. It will also try to check if all locations are available. If they aren't, then that should be debugging output, not an error, but it we must also ensure this lets users accept SSH host keys. Or, instead, we add a --dry-run or --simulate option to commands taking configuration? We can also add something like --interactive as a mutually exclusive option to -f in order to force commands to be interactive. In this mode the back-up and restore commands can tell rsync to ask for manual host key verification. The thing is that our API (backup() and restore()) is not coupled to the shell. If we tell these API functions to be interactive, they need to interact with stdin. We can build this in an API-ish way by making these functions accept a stdin file handler. If it exists, interactive mode is enabled. If it isn't, all interaction is disabled.
• Add Notifier.warn() which can be used to indicate why a command failed to execute, but if the cause isn't a problem, such as when no SSH location can be reached, because the command is run on cron and the machine is off Wi-Fi.
• Can we simplify locations? (#78)