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.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, was wondering if in future it would be reasonable to consume mount-s3 as a crate. We currently install it as a package and then invoke the binary as a subprocess. One thing that would be improved by crate consumption would be error handling. Currently a mount error spits out a Rust error as a string and the exit code doesn't communicate error type.
I see that crates from this repository are already published but there's disclaimers.
The text was updated successfully, but these errors were encountered:
Hey Jonathon, this is an interesting idea! While it's not something we're considering in-depth right now, it's something we discussed today as a possible way to help unblock some use cases like this.
For the error handling use case, we also have issue #721 to gather feedback about how we could improve error reporting/handling in Mountpoint. If there's anything specific you had in mind, we'd love to hear more.
I'm also curious if there are other customization you had in mind. Is it just error handling, or are there other parts you'd like to customize right now?
Tell us more about this new feature.
Hey, was wondering if in future it would be reasonable to consume
mount-s3
as a crate. We currently install it as a package and then invoke the binary as a subprocess. One thing that would be improved by crate consumption would be error handling. Currently a mount error spits out a Rust error as a string and the exit code doesn't communicate error type.I see that crates from this repository are already published but there's disclaimers.
The text was updated successfully, but these errors were encountered: