Ответ 1
Я реализовал такую функциональность в библиотеках для JVM и Rust. Вот что я узнал:
Разберитесь с именами приложений, потому что ваши пользователи не могут или не хотят.
Предоставьте API, которые вычисляют полный путь (включая имя приложения!) К каталогам конфигурации, кэша и т.д. Невыполнение этого требования приведет к тому, что код будет гарантированно ошибочным как минимум на 2 из 3 основных платформ, поскольку соглашения существенно отличаются.
Рассмотрим приложение, написанное компанией MegaCorp (веб-адрес MegaCorp.co.uk) под названием Foo App.
В Linux сегмент пути с именем приложения должен быть fooapp/ (в нижнем регистре, без пробелов), в Windows это должно быть MegaCrop\Foo App\ (обратите внимание на две папки), а в macOS это должно быть uk.co.MegaCorp.Foo-App (недопустимые символы заменено на -).
Четкое определение цели для каждого каталога.
Например, моя библиотека не предлагает runtimeDir в macOS или Windows, потому что XDG_RUNTIME_DIR сильно отличается от e. грамм. %TEMP% в Windows.
Это потенциальный источник проблем безопасности, так как каталог времени выполнения в Linux гарантирует, что доступ к нему может получить только владелец, удаляется при выходе пользователя из системы и т.д.
Также я предлагаю fontDir только для Linux и macOS. В Windows есть каталог шрифтов, но в отличие от Linux и macOS он недоступен для записи пользователем.
С другой стороны, я предлагаю dataDir (%APPDATA%) и dataLocalDir (%LOCALAPPDATA%) на всех трех платформах. В macOS и Linux эти каталоги возвращают один и тот же путь - это явное проектное решение, учитывающее, как пользователи будут писать код, если один из этих каталогов будет недоступен: пользователи либо забудут его обработать, либо просто откроют другой каталог. С выбранным дизайном это работает "из коробки", и пользователям не нужно думать об этом.
Избегайте проблем до того, как пользователь столкнется с ними.
Вот почему общие пути к кешу, каталогам конфигурации и т.д. возвращают %LOCALAPPDATA% и %APPDATA%, а специфичные для приложения пути к каталогам и каталогам конфигурации возвращают %LOCALAPPDATA%\Company\Application\cache и %APPDATA%\Company\Application\config.
Обратите внимание на подкаталоги! Это должно гарантировать чистое разделение кэша приложения, конфигурации и каталога данных независимо от того, какие странные настройки Windows могут быть у пользователя.
Разбейте варианты использования на отдельные модули.
В моей библиотеке есть три отдельных модуля с четко определенными отдельными случаями использования:
BaseDirs, который запрашивает пути невидимых пользователем стандартных каталогов (кеш, конфиг, данные, исполняемые файлы, каталоги времени выполнения) и настоятельно рекомендует вместо этого использовать ProjectDirs.
ProjectDirs, который вычисляет расположение каталогов кэша, конфигурации или данных для вашего собственного приложения или проекта, которые получены из стандартных каталогов.
UserDirs, который запрашивает пути стандартных пользовательских каталогов (Аудио, Документы, Загрузки и т.д.).
В то время как BaseDirs и UserDirs имеют довольно неинтересные конструкторы (new()), ProjectDirs предоставляет этот метод фабрики:
ProjectDirs::from(qualifier: &str, organization: &str, application: &str)
Этот метод гарантирует, что пользователи в конечном итоге получат правильные, совместимые со стандартами пути к каталогам кеша, конфигурации и т.д. Своих приложений, при этом им не нужно будет знать обо всех тонкостях каждой отдельной платформы.
Последнее предложение: я бы держал библиотеку с именем "Библиотека XDG Basedir", ориентированную на Linux, и публиковал бы библиотеку с более общим именем, например "Стандартная библиотека каталогов", которая работает с Linux, Windows и т.д., Чтобы избежать путаницы.
Надеюсь, это было полезно!