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

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

Open
ozkriff opened this Issue Jan 29, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@ozkriff
Copy link
Contributor

ozkriff commented Jan 29, 2019

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

This comment has been minimized.

Copy link
Contributor

icefoxen commented Feb 1, 2019

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

This comment has been minimized.

Copy link
Contributor Author

ozkriff commented Feb 2, 2019

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

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

@icefoxen

This comment has been minimized.

Copy link
Contributor

icefoxen commented Feb 2, 2019

'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. :/

@icefoxen icefoxen added the Type-CODE label Feb 5, 2019

@ozkriff

This comment has been minimized.

Copy link
Contributor Author

ozkriff commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Contributor

icefoxen commented Feb 13, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.