Bazaar does not follow the Freedesktop XDG Base Directory Specification

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

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

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

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.

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.

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.

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.

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.

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

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

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 =(

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?

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

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

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

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