according to the following rule,
^1.2.3 is >=1.2.3 <2.0.0
^0.2.3 is >=0.2.3 <0.3.0 (0.x.x is special)
^0.0.1 is =0.0.1 (0.0.x is special)
^1.2 is >=1.2.0 <2.0.0 (like ^1.2.0)
I am wondering why there is the difference as below between Semver ^12.1.0 and ^12.1.1 in my yarn.lock file?
^12.1.0 is resolved to 12.1.1, meanwhile
^12.1.1 is resolved to 12.3.0 (the latest version).
react-native-svg#^12.1.0:
version "12.1.1"
resolved "https://registry.yarnpkg.com/react-native-svg/-/react-native-svg-12.1.1.tgz#5f292410b8bcc07bbc52b2da7ceb22caf5bcaaee"
integrity sha512-NIAJ8jCnXGCqGWXkkJ1GTzO4a3Md5at5sagYV8Vh4MXYnL4z5Rh428Wahjhh+LIjx40EE5xM5YtwyJBqOIba2Q==
dependencies:
css-select "^2.1.0"
css-tree "^1.0.0-alpha.39"
react-native-svg#^12.1.1:
version "12.3.0"
resolved "https://registry.npmjs.org/react-native-svg/-/react-native-svg-12.3.0.tgz#40f657c5d1ee366df23f3ec8dae76fd276b86248"
integrity sha512-ESG1g1j7/WLD7X3XRFTQHVv0r6DpbHNNcdusngAODIxG88wpTWUZkhcM3A2HJTb+BbXTFDamHv7FwtRKWQ/ALg==
dependencies:
css-select "^4.2.1"
css-tree "^1.0.0-alpha.39"
any help would be appreciated, thanks.
Related
I've built a simple app with these dependencies:
[dependencies]
core-foundation = { version = "0.9", features = ["with-chrono"] }
With cargo 1.62.1 (a748cf5a3 2022-06-08). My platform is a Macbook Air M1 (the target might matter, not sure).
And I'm getting this error:
error: cyclic package dependency: package `chrono v0.4.21` depends on itself. Cycle:
package `chrono v0.4.21`
... which satisfies dependency `chrono = "^0.4"` of package `core-foundation v0.9.3`
... which satisfies dependency `core-foundation = "^0.9"` of package `iana-time-zone v0.1.42`
... which satisfies dependency `iana-time-zone = "^0.1.41"` of package `chrono v0.4.21`
If I clone core-foundation and build it myself using cargo build --features="with-chrono", I'm not getting any error.
Any idea how to investigate this issue?
Unfortunately, there isn't much you can do if the cyclic dependency occurs with crates you don't control. You could attempt to "fix" one of the crates by cloning and modifying it to avoid a problematic dependency and override your dependencies with the fixed version.
Your best bet is to notify the maintainers of the crates involved. If the issue only arose recently, you can try locking your dependencies to an earlier version as a workaround.
This particular issue seems to be resolved already. It likely happened when chrono added iana-time-zone as a dependency in version 0.4.21. However, the fix was for iana-time-zone to change its dependency from core-foundation to core-foundation-sys in version 0.1.45 to break the cycle.
error: failed to select a version for `syn`. \
... required by package `serde_derive v1.0.125`\
... which satisfies dependency `serde_derive = "=1.0.125"` of package `serde v1.0.125`
... which satisfies dependency `serde = "^1.0.125"` of package `mongodb v2.1.0`\
... which satisfies dependency `mongodb = "^2.1"` of package `wagmeet v0.1.0
\(/mnt/e/College/Eighth Semester/Crypto_Capable/wagmeet_app)`\
versions that meet the requirements `^1.0.60` are: 1.0.86, 1.0.85, 1.0.84, 1.0.83, 1.0.82, 1.0.81, 1.0.80, 1.0.79, 1.0.78, 1.0.77, 1.0.76, 1.0.75, 1.0.74, 1.0.73, 1.0.72, 1.0.71, 1.0.70, 1.0.69, 1.0.68, 1.0.67, 1.0.66, 1.0.65, 1.0.64, 1.0.63, 1.0.62, 1.0.61, 1.0.60
all possible versions conflict with previously selected packages.
previously selected package `syn v1.0.57`\
... which satisfies dependency `syn = "=1.0.57"`
\ of package `near-sdk-core v3.0.1`
... which satisfies dependency `near-sdk-core = "=3.0.1"` of package `near-sdk-macros v3.0.1` \
... which satisfies dependency `near-sdk-macros = "=3.0.1"` \ of package `near-sdk v3.0.1`
... which satisfies dependency `near-sdk = "^3"` of package `wagmeet v0.1.0 `\
failed to select a version for `syn` which could resolve this conflict
Cargo.toml file
[package]
name = "wagmeet"
version = "0.1.0"
edition = "2021"
[lib]
crate-type = ["rlib","cdylib"]
[dependencies]
near-sdk = "^3.1.0"
near-contract-standards = "^3.1.1"
mongodb = "2.0.0"
bson = { version = "2", features = ["chrono-0_4"] } # Needed for using chrono datetime in doc
tokio = "1"
chrono = "0.4" # Used for setting DateTimes
serde = "1"
serde_derive = "1.0.135"
Update
added the cargo.toml file
I have tried various versions nothing seems to be working for now. Is mongoDb even compatible with Near protocol?
There is a conflict between two of your dependencies: near-sdk requires exactly syn version 1.0.57, and mongodb requires at least syn version 1.0.60. Clearly both cannot exist together.
You have few solutions:
Patch near-sdk to support later syn versions. This is usually not recommended.
Upgrade near-sdk to the pre-release 4.0.0 (currently 4.0.0-pre.7) that supports later syn versions. This is an unstable version, and may break.
Downgrade mongodb to a version that supports syn version 1.0.57. The latest version that supports that is 1.2.5, so you need to specify in your Cargo.toml mongodb = "=1.2.5". But this relies on an old, unsupported version.
There is no "best solution". All solutions are bad. I would probably upgrade near-sdk to 4.0.0, but what to do depends on your needs.
Try the following methods...
check your patched dependencies are pointed to the correct source repository
if you use other project's Cargo.lock or change some dependencies as you go, remove target folder and build again
check compilation logs for incorrect dependency paths!
update your Rust
delete .cargo and .rustup directories
I was trying to install ripgrep_all using cargo install ripgrep_all. It gave the following error:
% cargo install ripgrep_all
Updating crates.io index
Installing ripgrep_all v0.9.6
error: failed to compile `ripgrep_all v0.9.6`, intermediate artifacts can be found at `/tmp/cargo-install5HlOMt`
Caused by:
failed to select a version for the requirement `cachedir = "^0.1.1"`
candidate versions found which didn't match: 0.3.0, 0.2.0
location searched: crates.io index
required by package `ripgrep_all v0.9.6`
Then I searched a bit and found:
It looks like cachedir yanked version 0.1.1.
And the solution was to:
cargo install --locked ripgrep_all
I was able to install it successfully. However, During the installation it said:
% cargo install --force --locked ripgrep_all
Updating crates.io index
Installing ripgrep_all v0.9.6
warning: package `cachedir v0.1.1` in Cargo.lock is yanked in registry `crates.io`, consider running without --locked
warning: package `smallvec v1.4.0` in Cargo.lock is yanked in registry `crates.io`, consider running without --locked
It made me curious. What does Yank mean in rust world?
It means that the package has been marked as "yanked". This is usually done when the authors of have package have a very compelling reason that a certain version of a package should not be used at all, and to very strongly suggest that the package should not be used. You can ignore yanks with --force to force yanked packages to be used, but that is usually a bad idea: packages were usually yanked for a good reason.
In your case: The yanked cachedir 0.1.X version is a completely different package with a different author than the newer versions. The older versions are unmaintained and cannot be updated (since cachedir now has a different owner who publishes a different package), so the new owner of cachedir yanked the older versions. smallvec 1.4.0 has a bug where it causes Undefined Behaviour when used with zero-sized types, and that UB is bad enough that it is exceedingly unlikely that you actually want to use that version. The fix to this is to update to a later version of smallvec that doesn't have that bug.
I've tried stack clean, and also removing .stack-work.
But still, every time I run build it unregisters 5 (the same) packages.
stack build --dry-run tells me the list, but not any reason why.
I've also recently upgraded from 1.4.1
Also, if it is not quite simple how to figure this out, I'd like to get back to using 1.4.1. Any simple way to downgrade haskell-stack to that version?
Edit 1
Downgrading to 1.4.0 didn't help. About 70 packages got unregistered and rebuilt, and after that I got into the same 5-unregister-loop.
So I thought, where else could have my local state be corrupted since ~yesterday? ~/.stack! So I've (re)moved my ~/.stack folder, and also .stack-work folder, thinking that if anything could have gone wrong it's in these two places, and now I am in an even worse of a rut. Now the constant unregister cycle includes 23 packages (some of them quite heavy) instead of just 5.
Would unregister locally:
cairo-0.13.3.1 (missing dependencies: gtk2hs-buildtools)
dump-0.3.0 (missing dependencies: haskell-src-meta, interpolatedstring-perl6)
entropy-0.3.7
ghcjs-dom-0.2.4.0 (missing dependencies: glib, gtk3, webkitgtk3)
gio-0.13.3.1 (missing dependencies: glib, gtk2hs-buildtools)
glib-0.13.4.1 (missing dependencies: gtk2hs-buildtools)
gtk2hs-buildtools-0.13.2.2 (missing dependencies: happy)
gtk3-0.14.6 (missing dependencies: cairo, gio, glib, gtk2hs-buildtools, pango)
haskell-src-exts-1.17.1 (missing dependencies: happy)
haskell-src-meta-0.6.0.14 (missing dependencies: haskell-src-exts)
here-1.2.9 (missing dependencies: haskell-src-meta)
hs-di-0.4.0 (missing dependencies: haskell-src-meta, interpolate, interpolatedstring-perl6)
interpolate-0.1.0 (missing dependencies: haskell-src-meta)
interpolatedstring-perl6-1.0.0 (missing dependencies: haskell-src-meta)
pango-0.13.3.1 (missing dependencies: cairo, glib, gtk2hs-buildtools)
reflex-0.5.0 (missing dependencies: haskell-src-exts, haskell-src-meta)
reflex-dom-0.4 (missing dependencies: ghcjs-dom, glib, gtk3, reflex, webkitgtk3, webkitgtk3-javascriptcore)
threepenny-gui-0.7.1.0
uuid-1.3.13
webkitgtk3-0.14.2.1 (missing dependencies: cairo, glib, gtk2hs-buildtools, gtk3, pango)
webkitgtk3-javascriptcore-0.13.2.0 (missing dependencies: glib, gtk2hs-buildtools, gtk3, webkitgtk3)
websockets-0.9.8.2
websockets-snap-0.10.0.0
#user2407038, what kind of information might help to start diagnosing this? Is the above helpful to begin with? Under what circumstances can ever such an unregister-loop arise?
I have one more idea that I could try: this particular project depends on a few local packages, and afaik their .stack-work folder may play a role in this. So maybe I could (re)move those as well.
Any more ideas should the above one fail?
Long story short: changing resolver: lts-7.19 to resolver: lts-7.24 in stack.yaml seems to have fixed the error for me.
I have some guesses and hunches what may have gone wrong in the background, but I am not entirely sure.
I got a clue from the --dry-run flag that some of the missing packages it reports are build-time haskell package dependencies, like alex, happy, etc...
So maybe the older lts didn't install those correctly? If someone is more knowledgeable on the subject, I'd love to hear more.
And I'm also sad that this incident has destroyed some of my trust in stack's promise of reproducible builds, as a (AFAIK purported-to-be-safe) stack upgrade (and even with subsequent downgrade) suddenly left one of my projects un-buildable for days.
And at any rate, I'd love if
stack would warn and ask me before it makes destructive changes on my system, especially if it results in hours of recompilation. (Which actually meant days of head-scratching in my case since any idea I tried I had to wait quite a bit of time in-between.)
It could employ a similar build store as nix, whereas even if I change some configuration, I can switch back to the previous working configuration readily.
As a partial solution, I found that I can
stack upgrade --binary-version 1.4.0
Which readily performs the downgrade:
Current Stack version: 1.5.1, available download version: 1.4.0
Forcing binary upgrade
Querying for archive location for platform: linux-x86_64-static
Downloading from: https://github.com/commercialhaskell/stack/releases/download/v1.4.0/stack
-1.4.0-linux-x86_64-static.tar.gz
Download complete, testing executable
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64
hpack-0.17.0
New stack executable available at /home/user/.local/bin/stack
It could have been the case the you were hitting this bug: Better calculation of SourceMap, but again not enough information to tell for sure. Considering that this issue will get fixed soon, it shouldn't be a problem anymore, but if anyone is looking for a work around custom snapshots seem to work pretty well.
The gist of custom snapshots is by moving all immutable packages from extra-deps into a custom snapshot will prevent stack from recalculating dependencies for these packages.
I want to use Yesod web framework with yesod-auth-oauth, but I encountered a dependency problem while cabal-dev install:
/Users/kenta/myapp/oryza% cabal-dev install
Resolving dependencies...
cabal: cannot configure yesod-platform-1.0.2. It requires data-default ==0.4.0
For the dependency on data-default ==0.4.0 there are these packages:
data-default-0.4.0. However none of them are available.
data-default-0.4.0 was excluded because authenticate-oauth-1.3.0 requires
data-default ==0.3.*
data-default-0.4.0 was excluded because data-default-0.3.0 was selected
instead
data-default-0.4.0 was excluded because oryza-0.0.0 requires data-default
==0.3.*
I don't have any idea of what's wrong.
What I did is just inserting one line in Cabal file:
yesod-auth-oauth >= 1.0 && < 1.1
The default scaffolding works fine, which is created through yesod init.
The version information
yesod-core: 1.0.1
cabal-dev: 0.9.1 (build with Cabal 1.14.0)
cabal-install: 0.10.2
GHC: 7.0.4
OS: Mac OS X Lion
Thanks.
This looks like an overly restrictive upper bound in the authenticate-oauth package. It would be best to follow up directly with the maintainer of that package.
In general, these kinds of issues are a side-effect of following the Package Versioning Policy. Basically, it's a trade-off between having these "refuse to compile" annoyances and more insidious "can't compile" problems.
I don't remember for sure, but I think my change to the cabal file for yesod-auth-oauth fixes this.