Stream: git-wasmtime

Topic: wasmtime / issue #4936 wasmtime 1.0.0's wasi-cap-std-sync...

Wasmtime GitHub notifications bot (Sep 20 2022 at 22:26):

philpax opened issue #4936:

Steps to Reproduce

• Update to a Rust nightly after the 27th of July
• Attempt to build wasmtime-wasi

Expected Results

The build completes successfully.

Actual Results

The build fails as the version of cap-std in use uses sealed traits in the Rust stdlib:

   --> C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\cap-primitives-0.25.3\src\fs
\file_type.rs:134:6
    |
134 | impl std::os::windows::fs::FileTypeExt for FileType {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::sealed::Sealed` is not
implemented for `file_type::FileType`
    |
    = help: the following other types implement trait `std::sealed::Sealed`:
              Child
              Command
              ExitCode
              ExitStatus
              ExitStatusError
              OsStr
              OsString
              Simd<f32, N>
            and 2 others
note: required by a bound in `std::os::windows::fs::FileTypeExt`

Versions and Environment

Wasmtime version or commit: 1.0.0

Operating system: Windows 10

Architecture: x86-64

Extra Info

This is caused by https://github.com/bytecodealliance/cap-std/issues/270, which has been fixed up by upstream cap-std. A v0.26.0-patch1 has been released that includes this fix, but it may be worth waiting for the 1.0.0? (not sure what y'all are planning internally.)

Prior to this, I was using wasmtime 0.39.1 with these patches:

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }

As wasmtime 1.0.0 depends on 0.25.3 specifically, I can no longer manually patch the relevant packages as there's no version of 0.25.3 with this fix on the Git repository, and (as far as I can tell, it's still a little mysterious to me) there's no way to patch with another version from crates.io (I'd patch with 1.0.0rc1 if it was possible)

This is currently blocking us from updating to 1.0.0; 0.39.1 still works fine, but would love to get in today's release hype :rocket:

Wasmtime GitHub notifications bot (Sep 20 2022 at 22:26):

philpax labeled issue #4936:

Steps to Reproduce

• Update to a Rust nightly after the 27th of July
• Attempt to build wasmtime-wasi

Expected Results

The build completes successfully.

Actual Results

The build fails as the version of cap-std in use uses sealed traits in the Rust stdlib:

   --> C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\cap-primitives-0.25.3\src\fs
\file_type.rs:134:6
    |
134 | impl std::os::windows::fs::FileTypeExt for FileType {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::sealed::Sealed` is not
implemented for `file_type::FileType`
    |
    = help: the following other types implement trait `std::sealed::Sealed`:
              Child
              Command
              ExitCode
              ExitStatus
              ExitStatusError
              OsStr
              OsString
              Simd<f32, N>
            and 2 others
note: required by a bound in `std::os::windows::fs::FileTypeExt`

Versions and Environment

Wasmtime version or commit: 1.0.0

Operating system: Windows 10

Architecture: x86-64

Extra Info

This is caused by https://github.com/bytecodealliance/cap-std/issues/270, which has been fixed up by upstream cap-std. A v0.26.0-patch1 has been released that includes this fix, but it may be worth waiting for the 1.0.0? (not sure what y'all are planning internally.)

Prior to this, I was using wasmtime 0.39.1 with these patches:

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }

As wasmtime 1.0.0 depends on 0.25.3 specifically, I can no longer manually patch the relevant packages as there's no version of 0.25.3 with this fix on the Git repository, and (as far as I can tell, it's still a little mysterious to me) there's no way to patch with another version from crates.io (I'd patch with 1.0.0rc1 if it was possible)

This is currently blocking us from updating to 1.0.0; 0.39.1 still works fine, but would love to get in today's release hype :rocket:

Wasmtime GitHub notifications bot (Sep 21 2022 at 10:26):

sunfishcode commented on issue #4936:

I think it makes sense to do a cap-std 0.26 release, with the fix, and update wasmtime to use that. I've now filed https://github.com/bytecodealliance/cap-std/issues/275 with more info.

Wasmtime GitHub notifications bot (Sep 21 2022 at 10:52):

philpax commented on issue #4936:

Seems reasonable - thank you for the speedy response! :heart:️

Wasmtime GitHub notifications bot (Sep 21 2022 at 19:56):

alexcrichton closed issue #4936:

Steps to Reproduce

• Update to a Rust nightly after the 27th of July
• Attempt to build wasmtime-wasi

Expected Results

The build completes successfully.

Actual Results

The build fails as the version of cap-std in use uses sealed traits in the Rust stdlib:

   --> C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\cap-primitives-0.25.3\src\fs
\file_type.rs:134:6
    |
134 | impl std::os::windows::fs::FileTypeExt for FileType {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::sealed::Sealed` is not
implemented for `file_type::FileType`
    |
    = help: the following other types implement trait `std::sealed::Sealed`:
              Child
              Command
              ExitCode
              ExitStatus
              ExitStatusError
              OsStr
              OsString
              Simd<f32, N>
            and 2 others
note: required by a bound in `std::os::windows::fs::FileTypeExt`

Versions and Environment

Wasmtime version or commit: 1.0.0

Operating system: Windows 10

Architecture: x86-64

Extra Info

This is caused by https://github.com/bytecodealliance/cap-std/issues/270, which has been fixed up by upstream cap-std. A v0.26.0-patch1 has been released that includes this fix, but it may be worth waiting for the 1.0.0? (not sure what y'all are planning internally.)

Prior to this, I was using wasmtime 0.39.1 with these patches:

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }

As wasmtime 1.0.0 depends on 0.25.3 specifically, I can no longer manually patch the relevant packages as there's no version of 0.25.3 with this fix on the Git repository, and (as far as I can tell, it's still a little mysterious to me) there's no way to patch with another version from crates.io (I'd patch with 1.0.0rc1 if it was possible)

This is currently blocking us from updating to 1.0.0; 0.39.1 still works fine, but would love to get in today's release hype :rocket:

Wasmtime GitHub notifications bot (Sep 22 2022 at 15:33):

philpax commented on issue #4936:

Aye, that's what I suspected - but is it possible to backport this under the bugfix policy? As far as I can tell, this is the only thing blocking us from updating to 1.0.

Wasmtime GitHub notifications bot (Sep 22 2022 at 16:01):

pchickey commented on issue #4936:

In my judgement, failing to build under Nightly doesn't meet the bar of "on-by-default behavior", though the RFC itself doesn't make that explicit. Nightly builds tend to break pretty often (once a month? more?) and it would be burdensome if we did a point release for all of them. Sorry to be the person to say no.

Wasmtime GitHub notifications bot (Sep 22 2022 at 17:58):

sunfishcode commented on issue #4936:

@philpax One workaround would be to pin to a nightly Rust version from before https://github.com/rust-lang/rust/pull/98583 landed.

Another workaround: If you'd like, I could create git branches of cap-std which have the fix and have a 0.25.3 version number. I can't publish those to crates.io because the fix is semver-incompatible with 0.25, but since you mentioned using git = dependencies above, if you could use a git = dependency on such a branch, that would be another workaround. Would that be helpful?

Also, part of the Wasmtime 1.0 announcement is that Wasmtime has a monthly release cadence, so in a month, we'll have a new release with the actual fix in it.

Wasmtime GitHub notifications bot (Sep 23 2022 at 11:18):

philpax commented on issue #4936:

In my judgement, failing to build under Nightly doesn't meet the bar of "on-by-default behavior", though the RFC itself doesn't make that explicit. Nightly builds tend to break pretty often (once a month? more?) and it would be burdensome if we did a point release for all of them. Sorry to be the person to say no.

Understandable, I'll make it work.

One workaround would be to pin to a nightly Rust version from before https://github.com/rust-lang/rust/pull/98583 landed.

Aye - unfortunately, we're using changes from after that nightly, so we're tied to it.

Another workaround: If you'd like, I could create git branches of cap-std which have the fix and have a 0.25.3 version number. I can't publish those to crates.io because the fix is semver-incompatible with 0.25, but since you mentioned using git = dependencies above, if you could use a git = dependency on such a branch, that would be another workaround. Would that be helpful?

That would be fantastic if possible! I'm more than happy to use a Git patch - that should resolve the issue for me until we can use 2.0.0 :smile:

Wasmtime GitHub notifications bot (Sep 23 2022 at 16:38):

sunfishcode commented on issue #4936:

Ok, I've now created a 0.26-with-a-0.25-version-number branch, which is the 0.26 branch with one patch applied, to change the version number to 0.25.4-backport0. Let me know if that doesn't work!

Wasmtime GitHub notifications bot (Sep 23 2022 at 18:13):

philpax commented on issue #4936:

Thanks! Unfortunately, it appears Cargo is intensely picky about how it decides to pick minor versions for patches, and will refuse to update 0.25.3 to 0.25.4-backport0 (but _will_ update 0.25.3 to 0.25.4, which I validated by making that change to your branch locally)

I'm wrapping up my week, so I'm in no particular hurry for a fix. Based on my experimentation, I think you would have to drop the -backport0 to make Cargo consider it as a viable candidate as a patch.

I don't want to take up too much of your time / make things too confusing on your end, so I'm happy to just maintain a 0.25.4-versioned fork of cap-std under our org for the next month (esp as you've shown that 0.26 is 0.25-compatible for wasmtime). Does that work for you?

Wasmtime GitHub notifications bot (Sep 23 2022 at 18:39):

sunfishcode commented on issue #4936:

Ah, I just added -backport0 because I thought it'd be helpful, but it isn't necessary. I added a patch to the branch to change the version to 0.25.5. Does that work? I'm happy to make minor tweaks if that's all that's needed. But also yeah, you can certainly maintain your own branch too if that's easier.

Wasmtime GitHub notifications bot (Sep 25 2022 at 11:52):

pinkforest commented on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

It needs to be same version in git.. e.g. branch / tag can be different but the Cargo.toml manifest has to be the same

Wasmtime GitHub notifications bot (Sep 25 2022 at 11:52):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

It needs to be same version in git.. e.g. branch / tag can be different but the Cargo.toml manifest has to be the same for Cargo to accept the crates.io patch

Wasmtime GitHub notifications bot (Sep 25 2022 at 11:53):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

Wasmtime GitHub notifications bot (Sep 25 2022 at 11:57):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

For the patch approach to work

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

Wasmtime GitHub notifications bot (Sep 25 2022 at 11:57):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

For the patch approach to work

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

If we can update the branch Cargo.toml version then that would work

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:01):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

For the patch approach to work

EDIT: Just saw it was done already :partying_face:

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

If we can update the branch Cargo.toml version then that would work

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:03):

pinkforest commented on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:04):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:05):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:08):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:12):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

Also NOTE: You need to absolutely gate this feature over 1.64.0 and for Windows - Otherwise it will break all builds on < 1.64.0

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:12):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

Also NOTE: You need to absolutely gate this patch over 1.64.0 and for Windows - Otherwise it will break all builds on < 1.64.0

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:13):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

NOTE: You need to absolutely gate this patch on >= 1.64.0 and for Windows - Otherwise it will break all builds on < 1.64.0

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:13):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

NOTE: Need to absolutely gate this patch on >= 1.64.0 and for Windows - Otherwise it will break all builds on < 1.64.0

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:13):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

NOTE: Need to gate this patch on >= 1.64.0 and for Windows - Otherwise it will break all builds on < 1.64.0

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:17):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

NOTE: Need to gate this patch on >= 1.64.0 and for Windows - Otherwise it will break all other builds on < 1.64.0

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:17):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

For the patch approach to work

EDIT: Just saw it was done already :partying_face:

EDIT.2: Now need to gate this patch to only Windows and >= 1.64.0 as otherwise it breaks < 1.64.0

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

If we can update the branch Cargo.toml version then that would work

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:22):

pinkforest commented on issue #4936:

I need to send a patch to make sure it gets gated in the patch branch

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:26):

pinkforest commented on issue #4936:

The patch breaks on < 1.64.0

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:70:57
   |
70 |         std::os::unix::fs::FileTypeExt::is_block_device(self)
   |         ----------------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:75:56
   |
75 |         std::os::unix::fs::FileTypeExt::is_char_device(self)
   |         ---------------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:80:49
   |
80 |         std::os::unix::fs::FileTypeExt::is_fifo(self)
   |         --------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:85:51
   |
85 |         std::os::unix::fs::FileTypeExt::is_socket(self)
   |         ----------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

For more information about this error, try `rustc --explain E0277`.

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:26):

pinkforest deleted a comment on issue #4936:

I need to send a patch to make sure it gets gated in the patch branch

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:26):

pinkforest deleted a comment on issue #4936:

The patch breaks on < 1.64.0

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:70:57
   |
70 |         std::os::unix::fs::FileTypeExt::is_block_device(self)
   |         ----------------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:75:56
   |
75 |         std::os::unix::fs::FileTypeExt::is_char_device(self)
   |         ---------------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:80:49
   |
80 |         std::os::unix::fs::FileTypeExt::is_fifo(self)
   |         --------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:85:51
   |
85 |         std::os::unix::fs::FileTypeExt::is_socket(self)
   |         ----------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

For more information about this error, try `rustc --explain E0277`.

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:27):

pinkforest edited a comment on issue #4936:

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

NOTE: Still testing this.. having some issues

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:27):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

For the patch approach to work

EDIT: Just saw it was done already :partying_face:

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

If we can update the branch Cargo.toml version then that would work

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:29):

pinkforest commented on issue #4936:

Patch doesn't seem to work when trying to build on either stable 1.64.0 or latest nightly in linux

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:70:57
   |
70 |         std::os::unix::fs::FileTypeExt::is_block_device(self)
   |         ----------------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:75:56
   |
75 |         std::os::unix::fs::FileTypeExt::is_char_device(self)
   |         ---------------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:80:49
   |
80 |         std::os::unix::fs::FileTypeExt::is_fifo(self)
   |         --------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

error[E0277]: the trait bound `cap_primitives::fs::FileType: std::os::unix::fs::FileTypeExt` is not satisfied
  --> /home/foobar/.cargo/registry/src/github.com-1ecc6299db9ec823/cap-fs-ext-0.25.2/src/file_type_ext.rs:85:51
   |
85 |         std::os::unix::fs::FileTypeExt::is_socket(self)
   |         ----------------------------------------- ^^^^ the trait `std::os::unix::fs::FileTypeExt` is not implemented for `cap_primitives::fs::FileType`
   |         |
   |         required by a bound introduced by this call
   |
   = help: the trait `std::os::unix::fs::FileTypeExt` is implemented for `std::fs::FileType`

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:33):

pinkforest commented on issue #4936:

Looking at the origiinal commit

commit 949f251bccbb84513fe81a427a46864c1e8ad82c

Date:   Tue Aug 23 13:02:57 2022 -0700

    Switch to custom `FileTypeExt` traits.

    std has recently sealed its `FileTypeExt` traits, so cap-primitives can
    no longer implement them for its own types. Fortunately, these traits
    are just used as extension traits, so we can just define our own copies
    of them, and implement those instead.

    Fixes #270.

It removed these and now it seems to have broken Linux ?

The non-patch branch was working fine in OSX / Linux and this error only happened in Windows

In the patch branch can we rollback how it was with unix and only apply the Windows specific stuff ?

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:33):

pinkforest edited a comment on issue #4936:

Looking at the original commit

commit 949f251bccbb84513fe81a427a46864c1e8ad82c

Date:   Tue Aug 23 13:02:57 2022 -0700

    Switch to custom `FileTypeExt` traits.

    std has recently sealed its `FileTypeExt` traits, so cap-primitives can
    no longer implement them for its own types. Fortunately, these traits
    are just used as extension traits, so we can just define our own copies
    of them, and implement those instead.

    Fixes #270.

It removed these and now it seems to have broken Linux ?

The non-patch branch was working fine in OSX / Linux and this error only happened in Windows

In the patch branch can we rollback how it was with unix and only apply the Windows specific stuff ?

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:33):

pinkforest edited a comment on issue #4936:

Looking at the original patch commit

commit 949f251bccbb84513fe81a427a46864c1e8ad82c

Date:   Tue Aug 23 13:02:57 2022 -0700

    Switch to custom `FileTypeExt` traits.

    std has recently sealed its `FileTypeExt` traits, so cap-primitives can
    no longer implement them for its own types. Fortunately, these traits
    are just used as extension traits, so we can just define our own copies
    of them, and implement those instead.

    Fixes #270.

It removed these and now it seems to have broken Linux ?

The non-patch branch was working fine in OSX / Linux and this error only happened in Windows

In the patch branch can we rollback how it was with unix and only apply the Windows specific stuff ?

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:39):

pinkforest deleted a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

For the patch approach to work

EDIT: Just saw it was done already :partying_face:

Cargo.toml manifest version field needs to be same version in git..

e.g. branch / tag name can be different but the Cargo.toml manifest in the tag has to be the same for Cargo to accept the crates.io patch

If we can update the branch Cargo.toml version then that would work

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:39):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

NOTE: Still testing this.. having some issues

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136

Wasmtime GitHub notifications bot (Sep 25 2022 at 12:47):

pinkforest edited a comment on issue #4936:

Yeah our is picking up 0.25.2 - I went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

│   │   │   ├── wasi-common v0.40.0
│   │   │   │   ├── cap-rand v0.25.2
│   │   │   │   ├── cap-std v0.25.2
│   │   │   │   │   ├── cap-primitives v0.25.2

Also Cargo.lock gets now updated via that branch.. thanks !

All not necessarily required - see warnings whether they were used in graph or not

I cannot bump lock to 0.26 as wasi-common 0.40 pins to 0.25

NOTE: Still testing this.. having some issues

Cargo.toml patch

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25-version-number" }

$ cargo update -p wasi-common

    Updating crates.io index
    Updating git repository `https://github.com/bytecodealliance/cap-std.git`
warning: Patch `cap-fs-ext v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
    Removing cap-primitives v0.25.2
      Adding cap-primitives v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)
    Removing cap-std v0.25.2
      Adding cap-std v0.25.5 (https://github.com/bytecodealliance/cap-std.git?branch=0.26-with-a-0.25-version-number#535747a0)

Can we ensure that this branch hangs around for a while until we manage to bump to 1 ? Cheers

For anyone curious I ended up having an adventure in Rust std first: https://github.com/rust-lang/rust/issues/102260
I'm tracking this here for lunatic: https://github.com/lunatic-solutions/lunatic/issues/136