borgmatic-collective/borgmatic
borgmatic-collective
/
borgmatic
14
57
Fork 41
Code Issues 53 Pull Requests 2 Actions Packages Releases 122 Activity

Don't recommend to sudo pip install #163

Merged
witten merged 3 commits from :docsfix/no-sudo-pip into master 2019-05-13 19:04:24 +00:00
Conversation 8 Commits 3 Files Changed 3 +16 -8
decentral1se commented 2019-05-11 23:17:13 +00:00
Contributor
Copy Link

Running a sudo pip install might bork a user's system Python configuration. It is safer to recommend a user site installation and note the $PATH issue. We could also recommend a virtual environment via https://virtualenv.pypa.io/en/stable/#introduction. Thoughts?

Running a `sudo pip install` might bork a user's system Python configuration. It is safer to recommend a user site installation and note the $PATH issue. We could also recommend a virtual environment via https://virtualenv.pypa.io/en/stable/#introduction. Thoughts?
witten commented 2019-05-12 01:21:48 +00:00
Owner
Copy Link

I generally share the sentiment of: You should use a virtualenv (or pip install --user or Docker container) wherever possible rather than installing things at the system level. However, I didn't originally do that in the documentation because that'd require: 1. A possible dependency on additional tooling that doesn't come with borgmatic (although that doesn't apply to --user), and 2. Would require selecting a particular method (like virtualenv) on behalf of the user. I kind of consider system installs the lowest common denominator way to install, even if they're generally not recommended.

I also kind of figure that people who are more worried about isolation may just use a Docker container or distro-specific package.

Having said all that, I'm not averse to switching things up. Interested in your thoughts here. Do you think --user or virtualenv is common enough these days that it's worth 1. Taking a documentation-level dependency, and 2. Making the documentation select an implicit winner?

I generally share the sentiment of: You should use a virtualenv (or `pip install --user` or Docker container) wherever possible rather than installing things at the system level. However, I didn't originally do that in the documentation because that'd require: 1. A possible dependency on additional tooling that doesn't come with borgmatic (although that doesn't apply to `--user`), and 2. Would require selecting a particular method (like `virtualenv`) on behalf of the user. I kind of consider system installs the lowest common denominator way to install, even if they're generally not recommended. I also kind of figure that people who are more worried about isolation may just use a [Docker container or distro-specific package](https://torsion.org/borgmatic/docs/how-to/set-up-backups/#other-ways-to-install). Having said all that, I'm not averse to switching things up. Interested in your thoughts here. Do you think `--user` or virtualenv is common enough these days that it's worth 1. Taking a documentation-level dependency, and 2. Making the documentation select an implicit winner?
πŸ‘ 1
witten commented 2019-05-12 03:46:25 +00:00
Owner
Copy Link

One other consideration: The default config files (/etc/borgmatic/config.yaml, etc.) are expected to exist at the "system level", even if it's not system Python. So it might be a little weird, for instance, to instruct the user to pip install --user borgmatic and then use borgmatic to consume config files that only root has access to.

One other consideration: The default config files (`/etc/borgmatic/config.yaml`, etc.) are expected to exist at the "system level", even if it's not system Python. So it might be a little weird, for instance, to instruct the user to `pip install --user borgmatic` and then use borgmatic to consume config files that only root has access to.
πŸ‘ 1
decentral1se commented 2019-05-12 08:54:00 +00:00
Author
Contributor
Copy Link

Good points!

The --user recommendation will not suffice with the current documentation patch as is ...

I don't think we should select "a winner", so to speak, but perhaps show a variety of recommended Python community practices. I don't want to overwhelm a new user but it's a structural issue of Python packaging and nothing borgmatic can solve.

How about:

  • Dropping into the root account and using a user install
  • Using a virtual environment and linking to /usr/bin/borgmatic

And then linking out to standard Python documentation around virtual environments and user package installs where needed. I'll try another patch ...

Good points! The `--user` recommendation will not suffice with the current documentation patch as is ... I don't think we should select "a winner", so to speak, but perhaps show a variety of recommended Python community practices. I don't want to overwhelm a new user but it's a structural issue of Python packaging and nothing borgmatic can solve. How about: * Dropping into the root account and using a user install * Using a virtual environment and linking to /usr/bin/borgmatic And then linking out to standard Python documentation around virtual environments and user package installs where needed. I'll try another patch ...
decentral1se commented 2019-05-12 09:08:25 +00:00
Author
Contributor
Copy Link

Actually, the "using a virtual environment" documentation is perhaps a bridge too far. I've got a new patch pushed now that uses the root account with a --user install. I think this sticks with what you have already (using the root account) but also mitigates against a global package installation problem. See what you think.

Actually, the "using a virtual environment" documentation is perhaps a bridge too far. I've got a new patch pushed now that uses the root account with a `--user` install. I think this sticks with what you have already (using the root account) but also mitigates against a global package installation problem. See what you think.
witten reviewed 2019-05-12 22:31:18 +00:00
witten left a comment
Owner
Copy Link

Seems like a reasonable iterative improvement! Thanks for taking the time to do this.

Seems like a reasonable iterative improvement! Thanks for taking the time to do this.
docs/how-to/set-up-backups.md Outdated
@ -8,3 +8,3 @@
least version 1.1.
Then, run the following command to download and install borgmatic:
Borgmatic generates configurations in `/etc/borgmatic/` and `/etc/borgmatic.d/`
witten commented 2019-05-12 22:29:47 +00:00
Owner
Copy Link

Technically this should probably be something like: "Borgmatic consumes configuration files from ...". Because it doesn't (by default) generate anything into /etc/borgmatic.d/.

Technically this should probably be something like: "Borgmatic consumes configuration files from ...". Because it doesn't (by default) generate anything into `/etc/borgmatic.d/`.
docs/how-to/set-up-backups.md Outdated
@ -11,3 +15,3 @@
```bash
sudo pip3 install --upgrade borgmatic
sudo pip3 install --user --upgrade borgmatic
witten commented 2019-05-12 22:30:39 +00:00
Owner
Copy Link

The docs/how-to/upgrade.md file probably also needs this same treatment in a couple of places?

The `docs/how-to/upgrade.md` file probably also needs this same treatment in a couple of places?
witten commented 2019-05-12 22:33:14 +00:00
Owner
Copy Link

And maybe docs/how-to/develop-on-borgmatic.md as well. I'm thinking about the tox install instructions.

And *maybe* `docs/how-to/develop-on-borgmatic.md` as well. I'm thinking about the `tox` install instructions.
decentral1se commented 2019-05-13 11:20:25 +00:00
Author
Contributor
Copy Link

Comments addressed πŸ‘

Comments addressed :thumbsup:
witten commented 2019-05-13 19:03:28 +00:00
Owner
Copy Link

Thank you! Note that these changes won't go "live" on https://torsion.org/borgmatic/ until I manually re-deploy there. (That's actually something that would be worth putting in CI at some point.)

Thank you! Note that these changes won't go "live" on https://torsion.org/borgmatic/ until I manually re-deploy there. (That's actually something that would be worth putting in CI at some point.)
witten closed this pull request 2019-05-13 19:04:24 +00:00
decentral1se deleted branch docsfix/no-sudo-pip 2019-05-13 20:39:23 +00:00
sdellenb commented 2019-05-14 11:50:09 +00:00
First-time contributor
Copy Link

FWIW, I've been using a separate pipenv for borgmatic & borgbackup for a week now and it's running smoothly after initial setup troubles (environment activation in cron, by different users, etc.).

Each method has its own kinks and pitfalls, so I don't know if there's a "best solution". 😎

FWIW, I've been using a separate `pipenv` for `borgmatic` & `borgbackup` for a week now and it's running smoothly after initial setup troubles (environment activation in cron, by different users, etc.). Each method has its own kinks and pitfalls, so I don't know if there's a "best solution". :sunglasses:
witten commented 2019-05-14 17:50:44 +00:00
Owner
Copy Link

Glad to hear it pipenv is working well for you! Agreed that each method has its pros/cons, and trying to enumerate them all in borgmatic docs would probably be too much. I'm happy to include links though.

Glad to hear it `pipenv` is working well for you! Agreed that each method has its pros/cons, and trying to enumerate them all in borgmatic docs would probably be too much. I'm happy to include links though.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug

   
data loss

   
design finalized

   
good first issue

   
new feature area

   
question / support

   
security

   
waiting for response
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#163
No description provided.
Delete Branch ":docsfix/no-sudo-pip"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?