bytecodealliance / bytecodealliance/cap-std

Getting the path of a Dir

オープン
#373 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Rust
スター
821
フォーク
57
平均マージ
1時間 16分
マージ済み PR(30日)
4

説明

Sometimes I'd like to be able to get the path for a `Dir`.

For example,

* logs or debugging
* passing the path to a separate process
* passing the path to a library that doesn't yet support the capability model

For example, in a personal project, I'm using the `git2` wrapper around `libgit2`. In order to call `Repository::clone(url, path)`, I need the path of the cache directory. I could use gitoxide, a pure rust implementation of git, however that would have the same problem. Maybe in the future we can make gitoxide use cap-std, but for now that's not an option.

Yes, some of these examples break the capability model, however, from a pragmatic point of view, that may be acceptable.

I'm not sure what the best approach here is, but in my personal project I'm using a wrapper like

```rust
pub struct DirWithPath {
dir: Dir,
path: PathBuf,
}
```

with a constructor like

```rust
pub fn open_ambient_dir>(path: P, ambient_authority: AmbientAuthority) -> io::Result {
Dir::open_ambient_dir(path.as_ref(), ambient_authority).map(|dir| Self {
dir,
path: path.as_ref().to_path_buf(),
})
}
```

and an `open_dir` method that concatenates the path:

```rust
pub fn open_dir>(self: &Self, path: P) -> io::Result {
let full_path = self.path.join(path.as_ref());
self.dir.open_dir(path).map(|dir| Self {
dir,
path: full_path,
})
}
```

One issue with maintaining my own wrapper is that I can't use e.g `ProjectDirs` from `cap-directories` because its methods return `Dir`s, so the paths are unknown. I would have to wrap `directories_next` directly.

I wonder if it would be useful for other people if something like this was added to cap-std (with appropriate warnings with respect to it breaking the capability model)?

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず、既存の cap-std の `Dir` API と `cap-directories` の `ProjectDirs` メソッドを確認し、次に提案された wrapper がパスをどのように追跡するかを調べます。完了条件は、合意された API と capability-model に関する警告の文書化です。この issue では、更新するファイルやテストは指定されていません。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
rust
領域
operating-systems, security
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。