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

Relax WIT directory structure #1461

Open
lann opened this issue Mar 19, 2024 · 0 comments
Open

Relax WIT directory structure #1461

lann opened this issue Mar 19, 2024 · 0 comments

Comments

@lann
Copy link
Contributor

lann commented Mar 19, 2024

Zulip context: https://bytecodealliance.zulipchat.com/#narrow/stream/327223-wit-bindgen/topic/WIT.20directory.20structure

Currently, most WIT tooling expects a specific directory layout, typically rooted in a directory named wit/:

wit/*.wit: Mandatory "default" package
wit/deps/*/*.wit: Optional "dependency" packages, which can be referenced by other packages

The only way to store multiple packages in the same place is to (often arbitrarily) partition them into one default package and all others as "deps". This is awkward for repositories that don't have exactly one natural default package, such as the WASI 0.2 repo (ref #1433).

I'm proposing two changes:

  • Relax this directory structure into basically one rule: any directory under a "WIT root" (including the root itself) that contains at least one .wit file will be parsed as a package.
  • Update tooling to accept multiple WIT root directories to resolve, still defaulting to ["wit/"] where appropriate.

These changes should be backward compatible with the existing layout and permit some new conventions, such as:

  • The WASI 0.2 repo doesn't have to change; if someone wants to consume it directly they can point at the entire preview2/ directory or individual preview2/* packages as WIT roots.
  • Projects with many dependencies can organize them by namespace, e.g. wit/wasi/{http,io}/*.wit, wit/my-namespace/[email protected]/*.wit
  • Registry tooling can use unambiguous paths with e.g. content-addressed files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant