[Feature Request] Switch to using System.IO.Abstractions for file logic
MeltyPlayer opened this issue · 4 comments
Hello! This is an awesome library you've put together, thank you so much for developing this!
I wanted to request switching the file IO logic from the built-ins (i.e. System.IO.File.WriteAllBytes()) to their System.IO.Abstractions equivalents? This library allows you to stub the filesystem for tests, allowing you to avoid the significant overhead of reading to/writing from the filesystem.
For an example of how this would be beneficial, I have a tool for ripping models with their rigs/animations from video games, and most of my tests are end-to-end tests where I verify the exported model matches what was expected. Currently, this requires writing the GLTF output files to a temporary directory and then comparing those to the expected outputs, which is relatively slow. I've been hoping to stub SharpGLTF's filesystem so that these files are written within RAM instead, which should significantly improve test latency.
Just a number of considerations:
By the name of the package I thought it was from Microsoft/dotnet, but it's actually from a "TestableIO" user... Just that alone is suspicious... Specially considering it's published under the System namespace.
Also, Microsoft already has another package which is called Microsoft.Fileproviders.abstractions ... But it hasa number of limitations, the biggest one being it has a read only API
there's definitely a need for a file system abstractions, but having multiple packages to choose from means the competition is open.
In the mean time you can look at the read/write to dictionary, and the ZIP implementation in the toolkit, which is what you're looking for
@MeltyPlayer "For an example of how this would be beneficial, I have a tool for ripping models with their rigs/animations from video games" and violate terms... not cool.
@vpenades I would leave it as is, and simply just run tests against actual models from the gltf example repo, and treat your own creations you persisted to disk/memorystream the same way. Only suggestion here is to add an overload for ModelRoot.Load to accept a stream as well, not just a filepath
ModelRoot.Load already has a Load from stream. The tricky thing is to resolve the paths for satellite files, but it is doable.
As I said, the Toolkit has an inplementation to open gltf files from within archives, and can be used as a baseline to create wrappers that load models from other file abstractions.
closing as not doable.