(0.5 feedback) access to ggez's file system without Context

[ozkriff]

I need to access GGEZ's filesystem to check some assets' hashes. I don't want to create a full Context for this (I don't need graphics, sound, etc) - it won't work on travis CI.

With GGEZ v0.4 it was possible to create a standalone fs:

let mut fs = Filesystem::new(APP_ID, APP_AUTHOR).expect("Can't create a filesystem");
fs.mount(std::path::Path::new(ASSETS_DIR_NAME), true);

... and check whatever I needed:

pub fn check_assets_hash(fs: &mut Filesystem, expected: &str) -> ZResult {
    let mut file = fs.open("/.checksum.md5")?;
    let mut data = String::new();
    file.read_to_string(&mut data)?;
    let real = data.trim();
    if real != expected {
        let error_code = 1;
        error!("Bad assets checksum {} (expected {})", real, expected);
        process::exit(error_code);
    }
    info!("Assets checksum is Ok");
    Ok(())
}

Can it be acheved with GGEZ v0.5? I can't find a way to crate a standalone Filesystem object. For the CI checks needs I can, of course, just open the file with std::fs::File using its full path, but that won't work with zip packed assets, for example.

[icefoxen]

It looks that in 0.5 you can create a standalone Filesystem object just fine, but it doesn't actually have any useful public methods on it. They're all there, just marked pub(crate). This is a reasonable use case, so what would be the best way to solve it?

Eventually I want to be able to specifically initialize only parts of a Context, partially for the sake of ggez's own CI. See #480 for status. But, until we get there, it would indeed be nice to be able to do this, since pretty much everything else in ggez depends on the Filesystem object being around one way or another.

[ozkriff]

They're all there, just marked pub(crate).

Why are they hidden in 0.5? I remember they were public in 0.4.

[icefoxen]

'Cause in 0.4 you accessed all the filesystem stuff via ctx.fs.do_whatever() and all the rest of the API via some_package::do_whatever(ctx), and in 0.5 I smoothed everything over to the second way. Then we ended up with a pile of redundant functions, so I marked them pub(crate). I'm mostly fine with making them public, it just makes a larger API surface that takes more work to explain and is less consistent.

Edit: Making it consistent so you only have to explain it once is basically what #480 is about. But, it's a lot of work. :/

[ozkriff]

Soo, the only option seems to make some of the Filesytem's methods public again, document the reasoning behind it in Filesytem's docs and live with this redundancy, right?

[icefoxen]

Sounds about right, yes. It's on my to-do list of Easy Things To Fix, I suppose.

[Vixeliz]

With the custom context change that happened recently. With a little more change to that ie not forcing graphics context and such on the context custom build that may fix this issue