cargo fetch can't pull down deps for v0.8.0

[durin42]

I'm pretty sure I'm missing something obvious, but this works at main and not at v0.8.0 (but also worked at 9b2631c). We use cargo fetch to slurp down deps so we can satisfy requirements around non-use of the network during builds. Output:

augie% git checkout v0.8.0 > /dev/null
HEAD is now at 270a69e0 docs: document 0.8.0 release and link to blog post
augie% cargo fetch
    Updating crates.io index
error: failed to select a version for `pyembed`.
    ... required by package `oxidized-importer v0.8.0 (/Users/augie/Programming/pyoxidizer/oxidized-importer)`
versions that meet the requirements `^0.8.0` are: 0.8.0

the package `pyembed` links to the native library `pythonXY`, but it conflicts with a previous package which links to `pythonXY` as well:
package `pyembed v0.8.0 (/Users/augie/Programming/pyoxidizer/pyembed)`

failed to select a version for `pyembed` which could resolve this conflict

I'm confused because the pythonXY string doesn't show up many places and there don't seem to be any materially interesting changes around that between the tag and main. I'm happy to work on this, but I need some pointers to the right docs (either in pyoxidizer's code or in some Cargo docs) to get un-stuck. Thanks!

[indygreg]

Yeah, I was getting this when attempting to cargo publish --manifest-path pyoxidizer/Cargo.toml.

I'm unsure what's going on here. It seems like some weird cargo behavior, possibly a bug worth reporting.

I worked around it by commenting out the oxidized-importer entry from the Cargo workspace definition in the root Cargo.toml. Don't ask me how that fixed things.

[durin42]

Yeah, I'm unclear what's going on here, and @benbrittain is too. I suspect this has something to do with pyembed both being part of the workspace and being a dep, and cargo is somehow confused by that, but that's just a guess with no facts to back it up.

[durin42]

I also can get things working if I remove pyembed from the top-level Cargo.toml, in case that helps as a diagnostic.

[indygreg]

When I created the v0.9.0 Git tag/commit, I purposefully commented out oxidized-importer from the root Cargo.toml workspace. I'm curious if this makes your life easier.

[indygreg]

Actually, the commit I pushed for the v0.9.0 tag looks to be busted for a different reason (bad Cargo.lock I think). FML. I may commit a sin and force push the tag...

[indygreg]

I've updated the v0.9.0 tag to e3ac816. I feel so dirty.

[nilp0inter]

I've updated the v0.9.0 tag to e3ac816. I feel so dirty.

FYI, I am trying to build v0.9.0 (using Nix) and I am getting this Cargo error:

++ env CC_x86_64-unknown-linux-gnu=/nix/store/qpr8zp6anrcd94cq6cgn3vv27nv54dyd-gcc-wrapper-9.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/qpr8zp6anrcd94cq6cgn3vv27nv54dyd-gcc-wrapper-9.3.0/bin/c++ CC_x86_64-unknown-linux-gnu=/nix/store/qpr8zp6anrcd94cq6cgn3vv27nv54dyd-gcc-wrapper-9.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/qpr8zp6anrcd94cq6cgn3vv27nv54dyd-gcc-wrapper-9.3.0/bin/c++ cargo build --release --target x86_64-unknown-linux-gnu --frozen
error: the lock file /build/source/Cargo.lock needs to be updated but --frozen was passed to prevent this
If you want to try to generate the lock file without accessing the network, use the --offline flag.

[indygreg]

I know I'm playing with fire by force pushing tags, but I force pushed 91be708d as tag v0.9.0 with an updated Cargo.lock file.

[nilp0inter]

I am having the exact same issue with the new tag v0.9.0 pointing to 91be708d.

[indygreg]

I released version 0.10.0 today. As part of this, I implemented a new release command (see the release/ directory) to automate the process of releasing.

The automated releasing creates tagged Git commits for every change to a package version. The oxidized-importer package is also removed from the workspace to avoid issues.

So I think that if you check out one of the new <package>-<version> tags in this repository (e.g. pyoxidizer-0.10.0) and run cargo fetch, things should just work.

Please close the issue if things work post 0.10.

If things are still broken, I'd appreciate newer steps to reproduce with one of the 0.10.0 tags / commits.

[nilp0inter]

FYI, I've just tried v0.10.3, and it compiles flawlessly. Thanks!

[indygreg]

Then I think we can call this closed!