Lann Martin (Mar 04 2024 at 16:03): Lann Martin (Mar 04 2024 at 16:03):Is the wit directory structure still serving us well? It seems like most of the "real" definitions end up needing to be in deps/ for reuse anyway which makes the naming a bit confusing.
Brainstorming: I wonder if it would make sense to change the file layout rules in this backward compatible way: any directory under the "wit root" that contains one or more .wits is a package. That would allow for a new simpler convention of e.g. wit/<package>/ or wit/<package>@<version>/ (for repos that store multiple versions)
Lann Martin (Mar 04 2024 at 16:09):I suppose some things would still require a default package but maybe as an incremental improvement that could be pushed out to an error closer to code that actually depends on it.
Alex Crichton (Mar 04 2024 at 16:42):I think that'd be reasonable yeah, I think it's also reasonable to parse deps even without a "root" package. The hope was that this deps format wouldn't last very long as a better tool to manage things would manifest, but that hasn't happened , so I think it'd be reasonable to work on making the file format better
Alex Crichton (Mar 04 2024 at 16:42):(and as part of making it better it'd probably also be good to document it somewhere...)
Alex Crichton (Mar 04 2024 at 17:20):I'll also note https://github.com/bytecodealliance/wasm-tools/issues/1433 here which points out https://github.com/WebAssembly/WASI/tree/main/preview2 can't be parsed natively by wit-parser right now
Lann Martin (Mar 19 2024 at 17:33):https://github.com/bytecodealliance/wasm-tools/issues/1461
Landon James (Apr 16 2024 at 04:30):I'm running into an issue with this as well. I had all of my wit files (mostly one interface per file) in a single wit/ directory all listed as the same package foo:runtime. To clean this up I moved most of the interfaces to a wit/deps/events/*.wit and gave them their own package name foo:events. But then trying to reference those interfaces from interfaces that are still in the original package results in an error:
Caused by:
0: failed to merge local target `/my/workspace/project/wit`
1: package not found
--> /my/workspace/project/wit/events.wit:6:7
|
6 | use foo:events/some-event.{my-event-container};
I'm wondering is the package in wit/deps/ needs a world or something else for it to be valid and findable by a package under wit/?
Lann Martin (Apr 16 2024 at 12:48):I think what you are describing ought to work. Are you able to post the files publicly somewhere?
Ryan Levick (rylev) (Apr 16 2024 at 13:13):Are you using cargo-component by any chance? If so you'll need to specify where the dependencies live as cargo-component doesn't follow the deps directory convention.
Landon James (Apr 16 2024 at 15:51):Ahh yes I am using cargo-component and that is good to know! Does that mean I can also get around having to nest them in wit/deps/ at all? I was only going for that because it seemed like the only way to make it work, but it would be much nicer if I could nest them in wit/somethingDescriptive/.
Peter Huene (Apr 16 2024 at 15:53):for cargo-component, dependencies can be located at any path (or from a component registry such as https://wa.dev). use cargo component add --target --path <path-to-dir> foo:events to add a target dependency to your Cargo.toml
Ryan Levick (rylev) (Apr 16 2024 at 17:11):@Peter Huene this is actually a good point to ask - is there a reason that cargo-component doesn't conform to the deps convention? I know it's not specified, but it does seem to be something that tooling is converging on (including this PR for the wit CLI)
Peter Huene (Apr 16 2024 at 17:13):The deps convention is internal to wit-parser and doesn't allow cargo-component to merge in dependencies that may not be on the file system (such as wit packages downloaded from the registry). cargo-component also doesn't like the "use whatever is on disk" approach given the otherwise explicitness of dependencies specified in Cargo.toml
Peter Huene (Apr 16 2024 at 17:14):in a "real" ecosystem, there wouldn't be a "deps" folder, just perhaps a location to vendor registry packages; i view the deps folder as something to get the tooling off the ground, not where the ecosystem should be trending towards
Peter Huene (Apr 16 2024 at 17:19):honestly, the fact that we're not yet at the point where a registry is central to our tooling experience is one of the greatest frustrations i've had in this space and definitely a contributor to me NOPEing out
Last updated: Nov 26 2024 at 00:12 UTC