Open tk3369 opened 6 years ago
I have a PR up over on StatFiles.jl that would use SASLib.jl instead of ReadStat.jl for sas7bdat
files: https://github.com/davidanthoff/StatFiles.jl/pull/2. That would automatically give you a) full FileIO.jl integration and b) full integration into the TableTraits.jl ecosystem (in particular one can then easily read into any of the sinks described at https://github.com/davidanthoff/IterableTables.jl).
In general I think there is real value in keeping packages like this one here small, lean and not burdened with too many integrations into various other packages. That is the model of TextParse.jl, ReadStat.jl and hopefully soon ExcelReaders.jl and I think it makes overall dependency management much easier. Integration with things like FileIO.jl, TableTraits.jl and DataStreams.jl can then live in other small wrapper packages like StatFiles.jl.
For FileIO.jl in particular there is no real mechanism to have multiple packages registered for one file type. Given that StatFiles.jl is already registered for sas7bdat
files, we would run into real issues when we then had two packages that tried to handle that file format (I think).
Integration with things like FileIO.jl, TableTraits.jl and DataStreams.jl can then live in other small wrapper packages like StatFiles.jl.
I agree. Isn't that the same philosophy as the design of the Unix system? We just need a lot of tools that can work together seamlessly. I will put this issue as well as #13 on hold for now. I have other things to worry about... such as performance ;-)
See https://github.com/JuliaIO/FileIO.jl