Archiving cap-std
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 15/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- rust
- Domain
- operating-systems, security
Research direction
No files, tests, or entry points are named, and the issue asks for questions or concerns rather than a defined implementation task. Read the migration and archiving plan first; completion is not specified for an independent contribution.
Written by the indexing model from the issue text.
Description
cap-std was originally built for the purpose of implementing the original vision for wasi-filesystem, for Wasmtime. Since it was first launched, we've learned several lessons.
One of the big ones was that the whole preopens design in wasi-filesystem and the RESOLVE_BENEATH filesystem semantics, that cap-std implements, and that were inspired by CloudABI and Fuchsia, have not turned out to be worthwhile for wasi-filesystem. They're too different from the kinds of filesystem APIs that the vast majority of developers and existing code are expecting. And at the same time, they're not different enough to deliver sufficiently compelling advantages for WASI's use cases. I believe there is now broad consensus to migrating wasi-filesystem to a different style of filesystem semantics. There are still some open questions about exactly how that will work, but in any case, I expect there will be a need to change the implementation code in a way that wouldn't make sense for cap-std as we currently know it.
Also, maintaining cap-std as an independent library has turned out to make the code more complex to maintain, because it has meant that wasi-filesystem semantics were awkwardly split, with part being handled by code in Wasmtime and part by code in cap-std.
And, just having two repositories instead of one made things like security updates more complex, because we have to release cap-std packages separately from Wasmtime packages.
So, the plan is to vendor the parts of cap-std's code that Wasmtime needs into the Wasmtime tree directly, no longer published as an independent library. With that, the Bytecode Alliance doesn't have a need for maintaining the independent cap-std repository anymore, so I'm considering marking the repository as archived.
But before I make any changes, I'm happy to answer any questions or concerns anyone might have here.
- Dominant language
- Rust
- Stars
- 821
- Forks
- 59
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bytecodealliance/cap-std
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
bytecodealliance/cap-std#427 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
bytecodealliance/cap-std#416 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
bytecodealliance/cap-std#423 · 5 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 42/100
bytecodealliance/cap-std#408 · 4 comments · 2 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
bytecodealliance/cap-std#406 · 1 comment · 2 reactions ·
All issues in bytecodealliance/cap-std
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
state:needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
zed-industries/zed#64680 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
RustPython/RustPython#8802 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
TheLarkInn/aipm#2390 ·