More specific error when failing to create XDG fallback trash directory

[takluyver]

We've run into some issues with Jupyter where people couldn't delete a file such as /usr/local/src/sage-config/Untitled.ipynb . These files are on a different device to the home directory, and so send2trash's XDG implementation correctly goes and looks for /.Trash, which doesn't exist, and then tries to create /.Trash-$UID, which the user doesn't have permission to do.

I think it's perfectly reasonable for send2trash to throw an error in that case and let the application decide what to do. But it's a generic error, and we can't easily distinguish it from e.g. not having permission to delete the file at all. The best thing I can think of is a crude check that will only use send2trash if files would go to home-trash.

Would it be possible to define a more specific exception type, so that our application code can identify failures where we don't have permission to create the trash directory?

[ghost]

It's a good idea. Since you're more contextually aware than I am of this issue, I'd be glad to let you decide of a proper exception structure and naming @takluyver :) I'll be glad to merge a PR to that effect and prepare a release.

[takluyver]

Thanks, I'll have a go at that tomorrow.

[takluyver]

Closed by #21 and #22. For anyone reading this, the exception is called TrashPermissionError.

There's a caveat that if the Gio backend is used, there might be some other errors that get translated to this, if they use the same 'not supported' error code. Unfortunately I don't know of any way to prevent that.

[takluyver]

@hsoft that just led me to think: why is the Gio backend there? Are there problems you're aware of with send2trash's own XDG Trash implementation?

I can see the appeal of 'use a native library, fall back to some Python code', but it means that S2T has two totally different code paths depending on some state that's not always obvious or easy to change. To debug any reported problems, we have to work out which backend was in use. And if we want to add some feature (e.g. #4), it's complicated by the two backends. I don't want to have to explain to people 'this feature is only available if you can't import Gio'.