Bazaar does not follow the Freedesktop XDG Base Directory Specification

Bug #195397 reported by Tim Kersten on 2008-02-25
54
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Neil Martinsen-Burrell
bzr (Ubuntu)
Medium
Unassigned

Bug Description

The specification can be found at: http://standards.freedesktop.org/basedir-spec/latest/index.html

From the specification:

##########################################
There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.
##########################################

The reasoning behind this is so that it's easy to remove config files while not affecting any user data. This is especially important when a user upgrades their OS, i.e. Ubuntu 7.10 -> Ubuntu 8.04, and wants to start with the default settings for their applications. It will also help organise the ever so horrid mess in the home folder.

A simple rule might be:
Data for which there exists sane defaults, is config data. Data which should not be lost is user data.

Related branches

James Westby (james-w) wrote :

Hi,

I think it's a good idea for us to do this, but we need
to come up with a transition plan.

I guess this is a very common situation to be in, there isn't
by any chance any support for doing this somewhere is there?

Thanks,

James

Changed in bzr:
importance: Undecided → Wishlist
status: New → Triaged

I don't know of any support for transitioning, and I can well imagine
it not being a painless process. Perhaps the most sane default would
be something along the following:

If $HOME/.bazaar exists, let users know that this is now deprecated,
and ask if they would like to migrate to the new config scheme now, or
do so with a command later. Warn them that if they have any other
scripts or programs that use the old .bazaar config, it may break.

If it doesn't exist, use the new scheme. If both exist, use the new
scheme, but warn that an old scheme exists, explaining the transition
so that users now where to find the new settings and user data.

Of course this sounds a lot easier said than done, and I'm writing
this from the perspective of a user who wants to be rid of the upgrade
annoyance he's met with every 6 months.

move all configs / user data to the new $XDG_CONFIG_HOME and
$XDG_DATA_HOME, without separating out details of files yet, so that
each file can be simlinked in the old location.

Perhaps it would be a good idea to first come up with a plan for
transitioning as other projects take on the specification too.

Regards,
Tim

On Mon, Feb 25, 2008 at 6:05 PM, James Westby <email address hidden> wrote:
> Hi,
>
> I think it's a good idea for us to do this, but we need
> to come up with a transition plan.
>
> I guess this is a very common situation to be in, there isn't
> by any chance any support for doing this somewhere is there?
>
> Thanks,
>
> James
>
>
> ** Changed in: bzr
> Importance: Undecided => Wishlist
> Status: New => Triaged
>
>
>
> --
> Bazaar does not follow the Freedesktop XDG Base Directory Specification
> https://bugs.launchpad.net/bugs/195397
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Mon, 2008-02-25 at 20:44 +0000, Tim Kersten wrote:
> I don't know of any support for transitioning, and I can well imagine
> it not being a painless process. Perhaps the most sane default would
> be something along the following:

Thanks for your comments.

My personal preference would be to get support for reading from these
locations in soon. Then in a couple of releases start a transition
proper by changing the docs to point to the new location, and using
them when autocreating the files. Then after a while we can start
warning the user if they are using the old location, then finally
stop supporting them in v2 or similar.

However, I am not sure whether we are ready for the .config/ .local/
split. Most of what is in there is configuration I think, with
the exception of plugins, which I guess are data.

This would be a long task it seems.

Thanks,

James

Gioele Barabucci (gioele) wrote :

Anyway, there is nice python library to assist you in using the XDG Base Directory spec: http://freedesktop.org/wiki/Software/pyxdg

dobey (dobey) wrote :

I've implemented this feature in the branch lp:~dobey/bzr/xdgconfigdir with a simple migration from the old ~/.bazaar directory. I don't think plugins makes sense in XDG_DATA_{DIR,HOME}, as they aren't data, but libraries. However there is no XDG_LIB_{DIR,HOME} specified, so I have not changed them for now.

Lionel Dricot (ploum) wrote :

Rodney > I think that plugins might go in XDG_CONFIG_HOME. My little trick :

- Deleting XDG_DATA_HOME will make the user scream and it will kill your cat. Backuping only XDG_DATA_HOME and non-hidden files should preserve everything that you cannot recover from somewhere else.

- Deleting XDG_CONFIG_HOME will put all softwares in their default configuration, like wanted by the packager. The user will not loose anything valuable but it might takes some time to reconfigure everything according to his needs. Also, copying XDG_CONFIG_HOME on another computer should be enough to have your own configuration automatically applied to this computer (but without your data, of course).

- Deleting XDG_CACHE_HOME will not be noticable by the user except some performance degradation (that might be important. Think about deleting the Tracker cache).

In that sense, it appears that plugins are really part of CONFIG. Deleting them will be noticable by the user but he will be able to recover and will not loose any data. Don't forget that some plugins might use XDG_DATA_HOME if they create user data but it's up to the plugin developper to do that.

Gioele Barabucci (gioele) wrote :

Any chance the XDG Base Directory (./bazaar -> ./config/bazaar/) could be implemented in time for 2.0? A new major revision like 2.0 looks like the correct place to make such a change.

Robert Collins (lifeless) wrote :

Its tagged wishlist, so no its not likely. Changing it is actually a lot of effort:
 - theres a lot of docs that have to be changed
 - we need a migration path for people upgrading who aren't new users
 - we'll need to test the migration carefully

And there are remaining issues like where plugins go, which are not trivial and may even require changing the XDG specification to have a place for them.

Martin Pool (mbp) wrote :

I agree with James that at least reading from this location would be good; we can defer the issue of automatically migrating. Arguably that could be done in packaging.

If ~dobey is happy with that branch he should propose it for merging, or someone else should update it and propose that.

I think plugins are probably closer to being data than configuration because (though it's unlikely) users might have plugins there with local modifications or that they can't easily restore. gnome-do puts its plugins under ~/.local/share so there's a precedent.

Changed in bzr:
importance: Wishlist → Medium
status: Triaged → Confirmed

Martin Pool wrote:
> Arguably that could be done in packaging.

Nope, it can't I'm afraid. We are talking about user data, and modifying
that in packaging is forbidden.

The closest we could get is patching bzr to do the migration in the
packaging, which is clearly not what we want to do.

Thanks,

James

Jelmer Vernooij (jelmer) on 2009-07-30
Changed in bzr (Ubuntu):
status: New → Confirmed
Dimitri John Ledkov (xnox) wrote :

I'm big fan of this spec and trying to convert most of my packages to support this.

The dist-utils --user option & python do the right =)

$XDG_CONFIG_DIRS/bazaar:
authentication.conf
bazaar.conf
builddeb.conf
gannotate.conf
ignore
locations.conf
rules
subversion.conf

$XDG_CACHE_HOME/bazaar:
bzr-svn is already using this (~/.cache/bazaar/svn)

And plugins must go to:
$XDG_DATA_HOME/../lib/pythonX.Y/site-packages/bzrlib/plugins
                             ^^^^
                             This
is not defined in XDG but python uses it and succesfully finds anything installed using ./setup.py install --user

Step 1 would be to start search for plugins in ~/.local/lib/pythonX.Y/site-packages/bzrlig/plugins
Step 2 start reading configuration data from config dir
Step 3 start telling people & plugin makers to switch.

I'll look into the branch linked to this bug =)

/me can't wait to clean up my home dir ;-)

Dimitri John Ledkov (xnox) wrote :

Just to confirm:

1) Removed system installed dulwich
2) Installed dulwich into ~/.local using ./setup.py install --user
3) Checked that PYTHONPATH is *not* set
4) Changed into a git repo. $bzr info works and tells me it's a git repo
5) Installed bzr-git plugin into ~/.local and bzr stopped recognising git repos =(

Andrew Bennetts (spiv) wrote :

Is $XDG_DATA_HOME/../lib/pythonX.Y/site-packages/bzrlib/plugins really the right spot? The "../" seems a little fragile, and the result definitely seems a step backwards for usability. It will make it much harder to install and manage plugins by hand simply by virtue of being a much deeper and harder to find directory, which would be an unfortunate regression.

Would it acceptable to at least leave a symlink in $XDG_CONFIG_DIRS/bazaar/plugins? Or perhaps there's another option?

Sense Egbert Hofstede (sense) wrote :

I can confirm this bug and am marking it as Triaged since an upstream task has been opened. I copy the importance from upstream.

More information on the spec and how and why to use it can be found at
http://freedesktop.org/wiki/Specifications/basedir-spec
http://ploum.frimouvy.org/?207-modify-your-application-to-use-xdg-folders

Changed in bzr (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
tags: added: xdg-user-dir
Vincent Ladeuil (vila) on 2010-12-02
Changed in bzr:
assignee: nobody → Neil Martinsen-Burrell (nmb)
milestone: none → 2.3b4
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bzr - 2.3.0~beta5-1

---------------
bzr (2.3.0~beta5-1) unstable; urgency=medium

  [ Jelmer Vernooij ]
  * Cherrypick fix for compatibility with python2.7 >= 2.7.1-2. LP: #693880
  * Switch to python-support. Closes: #568462
  * Add missing build dependency on python-configobj.
  * Make dependency on python-testtools versioned (>= 0.9.5).
  * Re-remove included elementtree and configobj. Closes: #555343, #555336

  [ Vincent Ladeuil ]
  * New upstream release.
   + Fix https python-2.7 compatibility. Closes: #608085
   + Follow the Freedesktop XDG Base Directory Specification. LP: #195397
  * Drop unnecessary dependency on graphviz.

  [ Max Bowsher ]
  * Run testsuite for bundled plugins too.

  [ Jelmer Vernooij ]
  * Cherrypick fix around default locales.
 -- Jelmer Vernooij <email address hidden> Tue, 25 Jan 2011 18:25:51 +0000

Changed in bzr (Ubuntu):
status: Triaged → Fix Released
Antono Vasiljev (antono) wrote :

somehow bzr stores it's configs in ~/.bazaar again.

$ bzr version
Bazaar (bzr) 2.5.0
  Python interpreter: /usr/bin/python 2.7.3rc1
  Python standard library: /usr/lib/python2.7
  Platform: Linux-3.2.0-18-generic-x86_64-with-Ubuntu-12.04-precise
  bzrlib: /usr/lib/python2.7/dist-packages/bzrlib
  Bazaar configuration: /home/antono/.bazaar
  Bazaar log file: /home/antono/.bzr.log

Jelmer Vernooij (jelmer) wrote :

Bazaar will only use ~/.config/bazaar if it already exists. Does it exist?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers