Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate with FileIO #2

Open
tk3369 opened this issue Dec 27, 2017 · 2 comments
Open

Integrate with FileIO #2

tk3369 opened this issue Dec 27, 2017 · 2 comments

Comments

@tk3369
Copy link
Owner

tk3369 commented Dec 27, 2017

See https://github.com/JuliaIO/FileIO.jl

@davidanthoff
Copy link
Contributor

I have a PR up over on StatFiles.jl that would use SASLib.jl instead of ReadStat.jl for sas7bdat files: queryverse/StatFiles.jl#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).

@tk3369
Copy link
Owner Author

tk3369 commented Dec 30, 2017

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 ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants