PathBuf is not supported as a property

[olvrlrnz]

Hi,

I have a service which exposes some properties. When I tried to add another one of type Vec<PathBuf>, it fails to compile

error[E0277]: the trait bound `Vec<PathBuf>: TryFrom<OwnedValue>` is not satisfied
   --> src/lib.rs:34:31
    |
 34 |     fn property_one(&self) -> zbus::fdo::Result<Vec<PathBuf>>;
    |                               ^^^^ the trait `TryFrom<OwnedValue>` is not implemented for `Vec<PathBuf>`

I read #977 but FilePath doesn't help here. I hacked together impl From<PathBuf> for OwnedValue and impl<'v> From<PathBuf> for Value<'v> to send OsStrExt::as_bytes - and it worked.

I do understand the requirement for OwnedValue and the lossy PathBuf -> String -> PathBuf cycle, but what's the alternative - use a newtype and manually implement the required traits?

[zeenix]

I do understand the requirement for OwnedValue

It's explained briefly in our book but if you have suggestion for expanding it, I'm all ears. :) The reason owned version is needed is because interfaces can't borrow from self. I would very much like to lift this restriction but it's not easy.

the lossy PathBuf -> String -> PathBuf cycle

Not sure I understand. We're keeping the actual encoding as CStr inside the wrapper FilePath and encoding and decoding FilePath directly as an array of bytes. Maybe I'm missing something?

but what's the alternative - use a newtype and manually implement the required traits?

Contribute a PR that adds the missing trait impls to FilePath? The best path would be to add manual impl for CStr and then just use the Value and OwnedValue derive macros on the FilePath.

[olvrlrnz]

The problem is that I have the PathBuf inside a struct embedded in another container:

pub struct Volume {
    device_path: String,
    mount_path: PathBuf,
}

pub struct Volumes {
    active: Vec<Volume>,
    available: Vec<Volume>,
}

pub struct Service {
    // exposed as property
    volumes: Volumes,
}

If I use FilePath, I have to add lifetime annotations to everything touching a Volume. Also, what's the reason FilePath is using a CString internally? IMHO a Path should only be converted to a CStr at the FFI boundary, otherwise what's the point of having to separate types in the first place?

Currently, I've implemented everything manually in a newtype, which works well for my use case: gist

[zeenix]

The problem is that I have the PathBuf inside a struct embedded in another container:

Why is that a problem? 🤔 If both String and PathBuf have the *Value conversions implemented, it should just be a matter of deriving Value and OwnedValue on your structs.

If I use FilePath, I have to add lifetime annotations to everything touching a Volume

Not really, you can use 'static lifetime, can't you? If it helps, we can add an OwnedFilePath but it'll just be a wrapper around FilePath<'static>, just like OwnedValue is a wrapper around Value<'static>.

Also, what's the reason FilePath is using a CString internally?

I don't quite remember. It was a contribution from @yassinebenarbia and I reviewed it. The discussion was mainly in the PR, #1010. We can always change the implementation if you've a better idea. A PR would be the best way in that case. :)

[olvrlrnz]

I've tried to implement something. Would you mind having a look at zpath?

[zeenix]

I've tried to implement something. Would you mind having a look at zpath?

Thanks. Could you please provide a PR instead?

---

If the API needs to be broke, you could still provide the PR, we'll just need to put in the 6.0 queue.