Comments (7)
Hi @gwillem
I suggest dropping it altogether to prevent further confusion.
Can you please explain the confusion part? The xdg.DataDirs
(which is represented by the XDG_DATA_DIRS
environment variable) contains additional paths which can be used by applications to store data files in. The main path relative to which applications should store data files is xdg.DataHome
(represented by the XDG_DATA_HOME
environment variable). Both are defined by the XDG spec
so neither can be removed. Also, both xdg.DataHome
and xdg.DataDirs
are documented in the package.
xdg.DataDirs
can be used by itself and the same paths are also used by the xdg.DataFile
function as fallbacks for cases in which xdg.DataHome
is not a writable location, for any reason.
I was upgrading today from
v0.0.0-20190319220657-88e5137d2444
tov0.4.0
and my app broke, becauseDataDirs
is still present but doesn't seem to be used anymore (removed here: 1be1d4f#diff-5c0868fc869fb66c2b33ba837118f18c43f5002d0a3f8b9e11aceabe703d4b86L98)
The commit you are referencing is before the first ever release/tag of the library. I don't do breaking changes between minor releases of the application unless I absolutely have to, in which case, I mention it in the release notes. However, in this case, you were not even using a released version.
Also, the commit you are referencing does not remove the use of xdg.DataDirs
. The same paths are still used. See:
It is unfortunate that your app stopped working after the upgrade and while I don't know the exact reason for that, again, you were using an unreleased version of the library.
Also, you opened an issue which implies that I made a breaking change (which I did not) and your proposed solution is that I make a real breaking change, by removing xdg.DataDirs
.
This is not a real issue and needs to be closed.
from xdg.
For the record, I am not accusing anyone, I am only grateful that you made this package, thanks for that!
while I don't know the exact reason for that
Commit 1be1d4f1c3bb00cccaa31a0a8044278c1c0d1cc6 changes from using DataDirs to using baseDirs.dataFile (which does not use DataDirs). So, AFAICT, DataDirs is no longer used internally, only exported.
func DataFile(name string) (string, error) {
- return createPath(name, DataDirs)
+ return baseDirs.dataFile(relPath)
}
from xdg.
xdg.DataDirs can be used by itself and the same paths are also used by the xdg.DataFile function as fallbacks for cases in which xdg.DataHome is not a writable location, for any reason.
Maybe I misunderstand?
func Test_xdgDataDir(t *testing.T) {
xdg.DataDirs = []string{"/tmp"}
xdg.DataHome = "/nonexistent_location"
path, err := xdg.DataFile("test.txt")
assert.NoError(t, err)
assert.Equal(t, "/tmp/test.txt", path)
// /Users/willem/Library/Application Support/test.txt
}
from xdg.
For the record, I am not accusing anyone, I am only grateful that you made this package, thanks for that!
while I don't know the exact reason for that
Commit 1be1d4f1c3bb00cccaa31a0a8044278c1c0d1cc6 changes from using DataDirs to using baseDirs.dataFile (which does not use DataDirs).
func DataFile(name string) (string, error) { - return createPath(name, DataDirs) + return baseDirs.dataFile(relPath) }
That is what I'm saying:
This is what xdg.DataDirs
was in the version you were using:
DataDirs = xdgPaths("DATA_DIRS", DataHome,
[]string{"/usr/local/share", "/usr/share"})
This is xdg.DataFile
:
func DataFile(name string) (string, error) {
return createPath(name, DataDirs)
}
In the "new" version, xdg.DataDirs
is:
DataDirs = baseDirs.Data
which is:
baseDirs.Data = xdgPaths(envDataDirs, "/usr/local/share", "/usr/share")
This is xdg.DataFile
:
func DataFile(relPath string) (string, error) {
return baseDirs.dataFile(relPath)
}
which is:
func (bd baseDirectories) dataFile(relPath string) (string, error) {
return createPath(relPath, append([]string{bd.DataHome}, bd.Data...))
}
In both versions, xdg.DataFile
and xdg.SearchDataFile
do the exact same thing.
from xdg.
xdg.DataDirs can be used by itself and the same paths are also used by the xdg.DataFile function as fallbacks for cases in which xdg.DataHome is not a writable location, for any reason.
Maybe I misunderstand?
func Test_xdgDataDir(t *testing.T) { xdg.DataDirs = []string{"/tmp"} xdg.DataHome = "/nonexistent_location" path, err := xdg.DataFile("test.txt") assert.NoError(t, err) assert.Equal(t, "/tmp/test.txt", path) // /Users/willem/Library/Application Support/test.txt }
Oh, I see now. Your application changes xdg.DataHome
and/or xdg.DataDirs
. They are not meant to be changed. They are "read-only" in that sense. Yes, in the version you are referencing, that would impact xdg.DataFile
. In any case, they are not used internally in xdg.DataFile
or xdg.SearchDataFile
in any of the released versions of the package.
Why do you want to change xdg.DataHome
/xdg.DataDirs
in your application anyway? xdg.DataHome
and xdg.DataDirs
default to the values of the $XDG_DATA_HOME
and $XDG_DATA_DIRS
environment variables, which are usually set by the system and you are supposed to use those paths. If they are not defined, the library provides appropriate locations for them.
If you really want to change them, although you should not need to, you can do something like:
os.Setenv("XDG_DATA_HOME", "/nonexistent_location")
os.Setenv("XDG_DATA_DIRS", "/tmp")
xdg.Reload()
path, err := xdg.DataFile("test.txt")
from xdg.
Thanks for checking!
Why do you want to change xdg.DataHome/xdg.DataDirs in your application
To run unit tests.. Setting the OS envs works indeed, it just took me a while to figure that out :)
from xdg.
Thanks for checking!
Sure, no problem.
Why do you want to change xdg.DataHome/xdg.DataDirs in your application
To run unit tests.. Setting the OS envs works indeed, it just took me a while to figure that out :)
Ah, ok. You were changing them in unit tests. That's fair enough.
from xdg.
Related Issues (15)
- Support more XDG directories HOT 4
- createPath might be doing to much HOT 3
- Plan 9 support HOT 3
- On windows please use KnownfolderPath HOT 4
- Parse ~/.config/user-dirs.dirs file HOT 7
- Custom file system support? HOT 4
- `Create` may set up wrong permissions for some directories in the path HOT 8
- Dupplicate `homeDir`'s implementation HOT 2
- macOS: do not use ~/Library/Preferences HOT 3
- Provide CacheDir function HOT 2
- Remove might be a bit to harsh HOT 3
- User directories are not localized HOT 1
- Request: Release the new version HOT 3
- Should not change permissions without consent HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xdg.