Skip to content
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

Merged
merged 32 commits into from
May 30, 2023

Conversation

ratchek
Copy link
Contributor

@ratchek ratchek commented Apr 4, 2023

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

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have read the CONTRIBUTING guide.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.

ratchek and others added 11 commits February 22, 2023 17:05
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.
@real-yfprojects
Copy link
Collaborator

real-yfprojects commented Apr 4, 2023

Note how you can write Fixed #1162 to close the issue when merging the PR.

@real-yfprojects
Copy link
Collaborator

There are some commits in the branch diff that do not belong to this PR. Can you fix that?

Copy link
Collaborator

@real-yfprojects real-yfprojects left a 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.

src/vorta/__main__.py Show resolved Hide resolved
src/vorta/__main__.py Outdated Show resolved Hide resolved
src/vorta/__main__.py Outdated Show resolved Hide resolved
src/vorta/__main__.py Outdated Show resolved Hide resolved
src/vorta/utils.py Outdated Show resolved Hide resolved
src/vorta/__main__.py Outdated Show resolved Hide resolved
@ratchek
Copy link
Contributor Author

ratchek commented Apr 4, 2023

There are some commits in the branch diff that do not belong to this PR. Can you fix that?

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?

ratchek added 6 commits April 5, 2023 09:25
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.
@real-yfprojects
Copy link
Collaborator

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?

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.

@ratchek
Copy link
Contributor Author

ratchek commented Apr 13, 2023

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.

@real-yfprojects
Copy link
Collaborator

This is how I do it:

Keep master branch in sync with upstream

git checkout master
git pull upstream

Now you can either merge master into the feature branch. This what many people do. Its the easiest method:

git checkout feature-branch
git merge master

However I prefer keeping clean and linear git histories. I therefore rebase my feature branch onto master:

git checkout feature-branch
git rebase 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 origin/master or upstream/master and than rebased onto master which wasn't in sync with the remote branches.

@ratchek
Copy link
Contributor Author

ratchek commented Apr 19, 2023

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:
When I resolve merge conflicts and commit the changes, what should I be putting in the commit message? Just a generic "merge changes from upstream"? That seems redundant and unhelpful, but I don't know what the alternative might be.

ratchek added 2 commits April 19, 2023 14:19
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.
@real-yfprojects
Copy link
Collaborator

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).

Merge conflicts are usually resolved by the merge commit itself without rewriting any previous commits. Only few commands rewrite git history.

When I resolve merge conflicts and commit the changes, what should I be putting in the commit message? Just a generic "merge changes from upstream"?

That's fine. The merge commit will have the commits with helpful descriptions as a parent. Mostly we squash PRs anyway.

src/vorta/application.py Outdated Show resolved Hide resolved
src/vorta/application.py Outdated Show resolved Hide resolved
src/vorta/application.py Outdated Show resolved Hide resolved
src/vorta/application.py Outdated Show resolved Hide resolved
@ratchek
Copy link
Contributor Author

ratchek commented May 11, 2023

So, I just realized that now there's this issue, where everything works fine, unless you call vorta with the --development flag and pass it a custom directory using relative paths. So for example, if you do vorta --development ./dev-mode. In that particular scenario, the link to logs in the misc tab doesn't work. The logs exist and they're in the correct folder, but the link doesn't work.
I would suspect the call to config on line 37 in views/misc_tab.py is happening before the actual modification of the config values, however if you supply the full path when you're running the program (for example vorta --development /home/username/path/to/project/folder/dev-mode), then everything works fine. Is it possible that the string interpolation is not unpacking the full path correctly?

@ratchek
Copy link
Contributor Author

ratchek commented May 11, 2023

Is it possible that the string interpolation is not unpacking the full path correctly?

Yup. That was it. Fixed it. Should be good now.

src/vorta/__main__.py Outdated Show resolved Hide resolved
src/vorta/application.py Show resolved Hide resolved
src/vorta/__main__.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@real-yfprojects real-yfprojects left a 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?

Comment on lines 365 to 373
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.',
)
Copy link
Collaborator

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?

@real-yfprojects
Copy link
Collaborator

Nice work, thanks!

@real-yfprojects real-yfprojects requested a review from m3nu May 29, 2023 20:54
@ratchek
Copy link
Contributor Author

ratchek commented May 29, 2023

Nice work, thanks!

Thank you so so much for guiding me through this and being so patient.

@m3nu
Copy link
Contributor

m3nu commented May 30, 2023

That's fine. I see you mostly changed XXX to config.XXX. Reminds me a bit of Django now.

Updating the docs would be important too. So people actually use this feature as intended.

@real-yfprojects
Copy link
Collaborator

Updating the docs would be important too. So people actually use this feature as intended.

Follow up issue: borgbase/vorta.borgbase.com#42

DaffyTheDuck pushed a commit to DaffyTheDuck/vorta that referenced this pull request Jun 14, 2023
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FR: Local config mode for development.
4 participants