No worries Thomas. I'll keep python-xdg as a separate project, it's not bad to have an alternative. I mostly enjoy the mimetype api, for which I have pretty extensive tests. Feel free to look around.<div class="gmail_extra">

<br clear="all">J. Leclanche<br>
<br><br><div class="gmail_quote">On Mon, Dec 3, 2012 at 9:46 PM, Thomas Kluyver <span dir="ltr"><<a href="mailto:thomas@kluyver.me.uk" target="_blank">thomas@kluyver.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_extra"><div class="im"><div class="gmail_quote">On 3 December 2012 21:08, Jerome Leclanche <span dir="ltr"><<a href="mailto:adys.wh@gmail.com" target="_blank">adys.wh@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

However I'd be more inclined to figure out if the *spec* not providing a fallback is a good idea. What's wrong with assuming .local/run or something?</blockquote></div><br></div>I think there are some security issues, although I'm not quite clear about the details. The spec also says that the runtime directory needs to support all Unix file-like features - named pipes, hard links, and so on. If the user's home directory is on NFS, for example, that may not hold. My understanding is that Ubuntu now creates an entire separate mount point (at /run/user) to ensure the conditions are met.<br>



<br>Thanks,<br>Thomas<br><br>P.S. Jerome, I haven't forgotten your suggestion that your python-xdg implementation should replace PyXDG. But I'm increasingly convinced that it's important to keep the API as stable as possible. It's already used in a lot of places, and I don't think many projects are interested in dealing with API changes. Even the refactoring I've done has accidentally broken a couple of things. So I've been focussing on adding tests (<a href="http://cgit.freedesktop.org/xdg/pyxdg/tree/test" target="_blank">http://cgit.freedesktop.org/xdg/pyxdg/tree/test</a> ) and docs (<a href="http://pyxdg.readthedocs.org/en/latest/index.html" target="_blank">http://pyxdg.readthedocs.org/en/latest/index.html</a> ). You're more than welcome to help with that - perhaps we should merge some of the bits of python-xdg that PyXDG doesn't yet have.<br>



</div>
</blockquote></div><br></div>