Dependency on vendored repo blocks publishing

[kenz-gelsoft]

kenz@KENZnoMacBook-Air wx-base % cargo publish
    Updating crates.io index
error: all dependencies must have a version specified when publishing.
dependency `wx-universal-apple-darwin` does not specify a version
Note: The published dependency will use the version from crates.io,
the `git` specification will be removed from the dependency declaration.

[kenz-gelsoft]

I thought optional dependency will be allowed on publishing. But it wasn't.

@ancwrd1 Could you give me any advice on this?

[ancwrd1]

You mean publish on crates.io? I think it requires that the dependency is also there but I haven't published them yet.

[ancwrd1]

I can probably publish version 0.1.0 or similar, but I also wanted to upgrade it first to wx 3.2, currently it's on 3.1.6.

[kenz-gelsoft]

Yes, I mean publishing on crates.io as an alpha release for now.

It is OK publishing your vendored crates too, but I think those repo are a bit special to be hosted on crates.io.

So I want to find another way to incorporate them into wxRust.

[kenz-gelsoft]

I prefer not specifying any real prebuilt binary crate.

Ideas

• Let both wxrust-config and vendored crates have same API and replacing by the latter.
• Introduce a placeholder crate and replace with the actual vendored repo.

1st approch looks cleaner but the 2nd may be more trivial.

[kenz-gelsoft]

I searched cargo command line option to override dependency temporarily, but not exist.

I'll explore an way to move those dependency out from library crates to sample crates.

[ancwrd1]

Publishing large binaries won't work, you are right. There is a max size limitation on the package size uploaded to crates.io. One possibility is to clone them manually from the build.rs script during building (somewhere under target directory), but I think this requires to change the build logic quite a bit. You can also disable this feature and dependencies for now and publish the alpha version which relies on system-wide wxWidgets.

[ancwrd1]

One solution could be to create a wx-src source-only crate which builds wxWidgets on the fly, similar to e.g. https://github.com/alexcrichton/openssl-src-rs and have it under vendored feature gate. It will surely significantly increase build times but only for the first build, and in many cases that might be acceptable.

[kenz-gelsoft]

Thank you for taking time on this.

I'm trying following approach:

• Simplify wxrust-config API requiement on #164 #165
• Add runtime (not buildtime) same API implementation for vendored crates (I will open PR for your crates)
  • Concretely, add pub fn wx_config() on each crate's lib.rs which resemble build.rs one.
  • Indirect usage on build.rs requires this.
  • as https://github.com/kenz-gelsoft/wx-x86_64-pc-windows-msvc/pull/2
• Override dependency only on sample executable crates (won't be published at crates.io)

[kenz-gelsoft]

Accidentally closed, reopen.

[kenz-gelsoft]

166 may work for single vendored repo by overriding wxrust-config dependency.

This mechanism doesn't work per-target repo.

I'll try to make a git repo crate (won't be published) to support multiple build-target vendoring.

• Create new repo(crate)
  • wxrust-vendored-config which has same metadata with wxrust-config crate.
  • Multiple crates with same metadata in one workspace is not allowed, so this must be another repo.
  • This crate provides same crate surface with wxrust-config crate by using https://github.com/kenz-gelsoft/wx-x86_64-pc-windows-msvc/pull/2 like runtime API for multiple prebuilt crates.
• This repo overrides wxrust-config 0.0.1 with patch.crates-io new crate.

[kenz-gelsoft]

Next, I'll try the placeholder approch if work.

The current approch doesn't work with cross toolchain situation as https://github.com/kenz-gelsoft/wxRust2/pull/166#issuecomment-1238736318.