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

Avoid file/dir name collisions by putting profiles in an isolated location #16

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jvinet
Copy link

@jvinet jvinet commented Apr 19, 2021

Moved profile root to $XDG_DATA_HOME/qutebrowser/profiles so profile names cannot collide with Qutebrowser data files (eg: webengine)

…names cannot collide with Qutebrowser data files (eg: 'webengine')
@@ -60,7 +60,7 @@ Released under the MIT Licence. See LICENCE file for full licence terms.
EOF

set -eu
QP_VERSION="0.0.1"
QP_VERSION="0.0.2"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this - if we want to bump the version we'll do this in a dedicated PR so it's clear.

@jtyers
Copy link
Owner

jtyers commented Apr 26, 2021

Thanks for the PR! Good thinking, this is sensible. I've left one comment on it - once that's resolved we can merge.

On versioning, at the moment this just has a straight master branch, but I can see it would benefit folks to have versioning around this as it appears to get some usage, so I'll put up a separate issue for that.

@jvinet
Copy link
Author

jvinet commented Apr 26, 2021

No problemo. Updated!

@markstos
Copy link
Contributor

This looks good to me, but is a breaking change. A release note should be added to note that manual migration is required for the upgrade by creating the directly and copying the folders into it.

@jtyers
Copy link
Owner

jtyers commented Nov 29, 2023

Thanks for your work on this folks. I've re-implemented qutebrowser-profile in Python which solves a few headaches with its implementation. Would it be possible to re-work this PR in Python?

I agree with @markstos that, as a breaking change, we need to add it to release notes. We may also be able to automate migration in most cases so perhaps should consider that (though I'm not sure how wide our userbase is!)

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.

None yet

3 participants