API enhancement about alpm.rs HOT 5 CLOSED

To turn a string into a cstring. You need to append a null byte to the end. If you pass in a String then you can take ownership of it and just append the byte.

If the function took in a str, then you'd have still have to allocate a buffer so you can append a byte to it.

This is why I went for String.

The actual cstring API takes in a Into<Vec<u8>> though and not into<String>. I made that change to make the docs look more normal. And I don't see many people wanting to pass in byte arrays.

For the second point, do you mean things like, description and URL? In that case, I'm not really sure what to do. I tried to make this API stick as closely to alpm as possible. And in alpm, if desc is empty, the function alpm_pkg_get_desc() actually returns an empty string, not a null pointer.

But I don't think I'm really against changing it, as long as it's consistent and doesn't make the API too annoying to use with options everywhere.

from alpm.rs.

For Path specifically, it's even worse. As Path is backed by OsString, the actual data stored is OS dependant, and the alpm functions expect a regular char*, so if we did take in a Path, we'd have to convert it back to the format alpm expects.

from alpm.rs.

OK, maybe it's more tricky than I thought. This is just because I use Paths when manipulating files.

I will probably use path.as_ref().to_owned().display().to_string() to convert my path.

For the second point, I think it's always easier with options given that you can do unwrap_or andok_or to manage the result.

E.g., I want to return an error when the architecture field is missing. In this situation I could do:

let arch = pkg.arch().ok_or(MyErrorType::MissingField)?;

Or if I want the same behaviour as now:

let arch = pkg.arch().unwrap_or("");

from alpm.rs.

I'm fine with making arch, desc, etc Options.

With the path stuff. The reason you howe to call . display() and can't just convert it to a string is that a path may contain not unicode so the conversion is lossy.

Thin is fine for displaying. But if you actually want to use the file then it may end up opening a different fine. Even if the chances are very low.

from alpm.rs.

OK! I'll do the modification ASAP.
Regarding the path stuff: another way to do is to use path.to_str().
sdl2_image use this, sqlite too.

from alpm.rs.