I’ve recently started work on a cross-platform approach to sending (and retrieving) files from the system trash. Linux support is roughly complete, and I’ll be tackling MacOS next. This could either take the form of a feature update to BaseDirs.jl, or I could make a new packages say Trash.jl for this.
I’m opening this thread to let people know this is happening, and give an opportunity for early feedback/comment/questions 
Given that XDG does attempt to have a $XDG_DATA_HOME/Trash, BaseDirs seems reasonable.
But dealing with partition-local trashes seems tricky.
Indeed, there’s a bit too it and I’m going to need to pull in Dates (and BaseDirs if done as a separate package) as a dep for this (BaseDirs currently only depends on Base).
Thankfully the logic is well-described in the Freedesktop Trash spec, and I know the author of trash-d which has been helpful.
The most annoying part so far has been getting a pure-julia replacement for du -B1 which has culminated in finding a stat doc innacuracy.
MacOS is going to be much more of a pain than it was with locating directories, as it looks like I’ll need to hook into the Objective-C runtime that apple ships.
Alternatively, I could try blending a Swift script like GitHub - sindresorhus/macos-trash: Move files and folders to the trash with the unofficial @_cdecl attribute (ref), and then either have that built/distributed with Yggdrissil or as a Pkg Artifact.
Windows seems like it will be a similar deal to earlier, calling the Win32 API with an expected amount of suffering and “why microsoft?” involved in the development.
BaseDirs.jl currently has a clear and clean scope, to provide information about (and optionally create) the specific base directories mentioned. Functionality to send/retrieve files in the system trash, while related, feels like it distorts that scope and makes it less clean.
On the other hand, a new package just for this seems excessive (I assume that contributes to the decision of people who have voted against it). Instead - at the risk of even more cross-platform finagling work - perhaps there’s a more general package you could create for such operations, including things like:
Of course, none of these need to be present initially in the package, it can just start off with the system trash handling features. These could just be things to help decide on a package name.
FilesystemExtras.jl was the first name that popped up in my head, but these aren’t strictly filesystem operations afaict, they live on the borderlands of filesystem/OS/desktop manager. Since people often do these operations via their system file manager, perhaps FileManager.jl? (Sounds a bit too general without that context though.)
Mmm, something weighing on my mind is that I really want BaseDirs to be small enough that it can be added on a whim to packages without worry — and hopefully before people do something worse like hardcode a particular OS’s approach or shoving everything under the julia depot.
I think it currently does that rather well, with 1.10 I see:
julia> @time using BaseDirs
0.000083 seconds (208 allocations: 19.539 KiB)
Testing the current trash code, it “blows up” using BaseDirs to ~0.02 seconds and ~20k allocations. While this is far from large, it is markedly less lightweight.
This does push me more towards making Trash.jl. At the same time, I’m wary of scattering such functionality too thin.
TBH I half feel that it would make sense for system base directory and trashing functionality to come with Base.Filesystems, but this is probably a controversial view.
It occurs to me that perhaps a best of both worlds approach could be to both create this menagerie of small packages, and then perhaps a meta-package called something like OsIntegrations that simply loads them all under a single API.
I’d be keen to hear more thoughts on this (and the wider topic of how system integration should be approached by Julia. It’s nice to have our own managed .julia but I think there’s a point where it makes sense to be a “good citizen” on the OS and recognise that the computer isn’t just a Julia machine[1] 
).
[1] I know we have Emacs users in our community (like me 
) but we don’t need our own take on GitHub - a-schaefers/systemE: 🤣 A lightweight systemd replacement written in Emacs lisp 🤣 and GitHub - ch11ng/exwm: Emacs X Window Manager
That sounds like the completely right solution to me. It allows us to load the meta-package for general usage, while allowing developers to only add the required parts as dependencies. All without duplicating the work. Perhaps a “Filesystem” github organization is in order? I am not sure if there are enough package for an org to make sense.
It may be reasonable, Trash.jl has also been argued as reasonable, and I find it more so. I would never have thought to look for XDG or BaseDirs.jl related to trash. Even as a Linux users, I don’t think about those. XDG is not for e.g. Windows, I see at BaseDirs.jl:
It is essentially an implementation of the XDG (Cross-Desktop Group) directory specifications, with analogues for Windows and MacOS for cross-platform. More specifically, this is a hybrid of:
The XDG base directory and the XDG user directory specifications on Linux
The Known Folder API on Windows
The Standard Directories guidelines on macOS
I’m first now hearing of “Standard Directories guidelines”, that may or may not have to do with trash.