-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a dev mode that allows for local storing of config files and logs #1682
Conversation
This does nothing for now except echo that it was called to terminal.
This adds tooltips to the settings as well as a 'info' button that shows the tooltip when hovering over it. * Add tooltips to settings. * src/vorta/store/models.py (SettingsModel): Add `tooltip` column. * src/vorta/store/migrations.py (run_migrations): Create `tooltip` column. * src/vorta/store/connection.py (init_db): Populate `tooltip` column. Increase `SCHEMA_VERSION`. * src/vorta/views/misc_tab.py (MiscTab.populate): Set tooltip of checkbox widgets. * src/vorta/store/settings.py : Add tooltips and update label of `override_mount_permissions` * Add *help* button to settings. * src/vorta/assets/icons/help-about.svg: Add info icon. * src/vorta/views/partials/tooltip_button.py: Implement `ToolTipButton`. * src/vorta/views/misc_tab.py: Add `ToolTipButton` for each setting with a tooltip. Add `set_icons` and connect it to palette change. * tests/test_misc.py (test_autostart): Update test. --------- Co-authored-by: real-yfprojects <[email protected]>
Fixes borgbase#1463. This makes the code count the database rows for the current profile only. Previously one could run a backup without any sources when one had sources configured in a different profile. * src/vorta/borg/create.py (BorgCreateJob.prepare)
This creates the option to use the --development or -D flags to launch vorta in development mode which stores all settings, cache, temp, and log files in the project tree instead of in the default places for the system. Allows for working on the project without it pulling in the settings from the system-wide copy of vorta that you use for your actual backups.
Note how you can write |
There are some commits in the branch diff that do not belong to this PR. Can you fix that? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for taking on this issue. That will be a very useful development feature.
Could you elaborate on that please? This is the first time I'm using git in a collaborative manner. I take it you mean that there are commits arising from me merging in work that other people did? How do I go about fixing that? |
This does nothing for now except echo that it was called to terminal.
This creates the option to use the --development or -D flags to launch vorta in development mode which stores all settings, cache, temp, and log files in the project tree instead of in the default places for the system. Allows for working on the project without it pulling in the settings from the system-wide copy of vorta that you use for your actual backups.
2b0b756
to
8e4a5a1
Compare
Yes, usually these commits aren't shown in the branch diff. Here they are because you somehow rewrote the commits making you the committer. I managed to fix this by running git rebase -i master And dropping the commits in question since they are already included in the master branch. I forced pushed the fixed branch, so you will have to update your local copy of it. |
Hi, this i a silly question, but you mentioned I made a mess of the git commits, so I figured I'd ask to make sure it doesn't happen again. When I'm pulling in changes from the vorta master repo into my local dev branch, should I be using merge or rebase? Basically, I'm not sure exactly what my workflow should be in regards to making sure that I stay on top of changes happening in the main repo. |
This is how I do it: Keep master branch in sync with upstream
Now you can either merge master into the feature branch. This what many people do. Its the easiest method:
However I prefer keeping clean and linear git histories. I therefore rebase my feature branch onto master:
The rebase will also remove all merge commits of master that occur after the diverging. I would be interested how you managed to get branch you had before. My only guess was that you might have merged |
Ok, that's pretty much exactly what I do most of the time. The problem is, I think whenever I get merge conflicts (and I think that's where I git those weird results last time - trying to resolve merge conflicts). Sidenote: |
Changes based on the discussion here: borgbase#1682 Biggest change is that src/config is rewritten to initialize the config variables while the program is running, so you need to import the whole module every time you use variables/constants from it. This was done to avoid duplicating code responsible for setting up the directory in which config data will be stored.
Changes based on the discussion here: borgbase#1682 Biggest change is that src/config is rewritten to initialize the config variables while the program is running, so you need to import the whole module every time you use variables/constants from it. This was done to avoid duplicating code responsible for setting up the directory in which config data will be stored.
Merge conflicts are usually resolved by the merge commit itself without rewriting any previous commits. Only few commands rewrite git history.
That's fine. The merge commit will have the commits with helpful descriptions as a parent. Mostly we squash PRs anyway. |
So, I just realized that now there's this issue, where everything works fine, unless you call |
Yup. That was it. Fixed it. Should be good now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Can you add type hints and docstrings?
src/vorta/utils.py
Outdated
parser.add_argument( | ||
'--development', | ||
'-D', | ||
nargs='?', | ||
const=DEFAULT_DIR_FLAG, | ||
help='Start vorta in a local development environment. ' | ||
'All log, config, cache, and temp files will be stored within the project tree. ' | ||
'You can follow this flag with an optional path and it will store the files in the provided location.', | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you specify a metavar
so that it doesn't say
usage: vorta [-h] [--version] [--daemonize] [--create PROFILE]
[--development [DEVELOPMENT]]
when running vorta --help
?
Nice work, thanks! |
Thank you so so much for guiding me through this and being so patient. |
That's fine. I see you mostly changed Updating the docs would be important too. So people actually use this feature as intended. |
Follow up issue: borgbase/vorta.borgbase.com#42 |
…borgbase#1682) Allows vorta to be called with the command-line flag `--development` or `-D` that will make it use a directory in the project tree to store all the settings, logs, and cache. This default directory will be called `.dev_config` and placed in the projects root. Also allows for a custom directory path allowing for multiple "configuration" folders at once. This can be used to prevent the vorta instance that a developer is working on from accessing the configuration files that they have set up for their personal backups. * .gitignore : Add `.dev_config`. * src/vorta/utils.py (parse_args): Add `--development` flag. The default will be `DEFAULT_DIR_FLAG`. * src/vorta/utils.py : Add `DEFAULT_DIR_FLAG`. * src/vorta/config.py : Add methods for populating the config directories exposed by this module. * src/vorta/__main__.py (main): Handle `--development` flag and update config directories if its specified. * Access config constants through the `config` module instead of importing them directly with `from .config import`. --------- Co-authored-by: yfprojects <[email protected]>
Description
Allows vorta to be called with a command-line flag that will make it use a directory in the project tree to store all the settings, logs, and cache.
Also allows for a custom directory path allowing for multiple "configuration" folders at once.
Related Issue
Fixes #1162
Motivation and Context
This can be used to prevent the vorta instance that a developer is working on from accessing the configuration files that they have set up for their personal backups.
How Has This Been Tested?
Just been tested in the terminal by me.
Screenshots (if appropriate):
Types of changes
Checklist:
I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.