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

make libpathrs Rust configuration sane #24

Closed
cyphar opened this issue Jan 25, 2020 · 2 comments · Fixed by #66
Closed

make libpathrs Rust configuration sane #24

cyphar opened this issue Jan 25, 2020 · 2 comments · Fixed by #66
Labels
api/rust Related to the Rust API. ideas welcome An open problem which doesn't have a clear resolution.
Milestone

Comments

@cyphar
Copy link
Member

cyphar commented Jan 25, 2020

The current method of configuration is a really bad idea (exposing structure internals of Root is going to cause problems, I can feel it in my bones). So we should instead use a different design, but it's unclear to me what the best approach is:

  • Just have methods to set (and possibly get) configuration of the object. It's not the nicest thing in the world, but it's fairly workable.

  • The most common approach is the "builder" method. The issue with it is whether there should be a way to modify the configuration after you've consumed the builder. If yes, then what is the point of the builder (you could just modify the configuration and not have a builder -- which is the alternative proposal). If no, and then how do we expose the builder method through the C API -- we'd need to have C builders which is just going to be absolutely awful.

Some follow-on questions (and my tentative answers):

  • Do people really care about modifying the configuration after the fact?

    • Maybe, I'm not too sure.
  • How do we deal with the try_clone case and modifying the configuration of the copy (ditto for from_file_unchecked)?

    • We could do it by making the builder take a variety of "source" arguments (so you can source from a directory -- creating a new builder -- or from an existing object or file handle). The configuration could be pre-loaded from the existing object if applicable. Downside is that the API would be something like:
let root = RootBuilder::new().source("/some/path").build()?;
let root = RootBuilder::new().source_file_unchecked(root_file).build()?;
// how do we do try_clone?
let root = old_root.try_clone()?.build()?; // ?!
let root = RootBuilder::new().source_root(old_root).build()?; // !?
let root = RootBuilder::new().source_file_unchecked(old_root.try_clone()?.into_file()).build()?; // lolno
@cyphar
Copy link
Member Author

cyphar commented Jan 25, 2020

Or maybe you could make the API for try_clone be the same as it currently is, but there is a way you can consume a Root (or Handle) and turn it into a builder?

let root = old_root.try_clone()?.rebuild().set_some_config().build()?; // maybe?

The other problem is what should Root::resolve return? A builder? Does that really make too much sense? Handles don't really have a nice point where you can insert a constructor-like setup...

@cyphar cyphar added this to the 0.1.0 milestone Sep 11, 2024
@cyphar cyphar added ideas welcome An open problem which doesn't have a clear resolution. api/rust Related to the Rust API. labels Sep 11, 2024
@cyphar
Copy link
Member Author

cyphar commented Sep 13, 2024

I ended up going with:

let root = Root::open(rootdir)?;

// Apply ResolverFlags::NO_SYMLINKS for a single operation.
root.as_ref()
    .with_resolver_flags(ResolverFlags::NO_SYMLINKS)
    .mkdir_all("foo/bar/baz", &perm)?;

// Create a temporary RootRef to do multiple operations.
let root2 = root
    .as_ref()
    .with_resolver_flags(ResolverFlags::NO_SYMLINKS);
root2.create("one", &InodeType::Directory(perm))?;
root2.remove_all("foo")?;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api/rust Related to the Rust API. ideas welcome An open problem which doesn't have a clear resolution.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant