gzreadall(filename) and gzwrite(filename, data)

[samoconnor]

Convenience functions to read/write directly from/to a named file.

I'm doing a cleanup of my local stash of convenience functions and thought that these might be generally useful.

gzwrite("/tmp/foo.gz", "hello")
gzreadall("/tmp/foo.gz")
"hello"

[kmsquire]

I have mixed feelings about this PR. On one hand, these seem like pretty useful functions.

On the other, all other gz prefixed functions in GZip.jl are simple wrappers around the same functions provided by zlib. They're exposed and exported, but the higher level access is really meant to be done through Julia's IO interface.

It's also the case that, while this library isn't deprecated, Libz.jl will probably give you a bit better performance. (Although it's function interface is rather nonstandard....)

(Travis failures are unrelated.)

[samoconnor]

See BioJulia/Libz.jl#12

[samoconnor]

See also samoconnor/Libz.jl@e95bdf1

[samoconnor]

closing in favour of BioJulia/Libz.jl#12

[kmsquire]

Despite my belief that Libz is probably a better library to use for new projects, I would be in favor of updating GZip.jl to follow the convention set by https://github.com/JuliaLang/julia/pull/14660.

I'm not as concerned about the gz* functions, but more the read* functions (although more of an argument could be made for the former now...)

[samoconnor]

Hi @kmsquire,

Fair enough, it's probably easiest for someone with commit access to Libz to just paste in sorting like the following:

readgz(filename::AbstractString) = gzopen(read, filename)
readgzstring(filename::AbstractString) = gzopen(readstring, filename)
writegz(filename::AbstractString, data) = gzopen(io -> write(io, data), filename, "w")

[kmsquire]

Just curious, are the changes to read and readstring backwards compatible? This package still works with Julia v0.3, so wondering if any of those changes would require a bit more scaffolding.

[samoconnor]

I don't see why the new read methods and readstring couldn't be back ported to v0.3 or v0.4 without breaking anything.

[kmsquire]

Anything that adds or changes functionality probably won't actually be backported--my understanding for Julia is that, by convention (and following Semantic Versioning), patch version number changes (changing y for v0.x.y) imply only bug fixes.

(That, and backporting would probably inadvertently break someone's code when they target the new API and then try to run on a slightly older version of Julia.)

But, they could be added to Compat.jl, and then used in code targeting multiple Julia versions.

[nalimilan]

Indeed, @samoconnor, could you add the changes you made in JuliaLang/julia#14660 to Compat.jl?