-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot build with "dtype-categorical" enabled #19063
Comments
Hashbrown just updated to 0.15, with the following section in the changelog: Polars takes a workspace dependency on hashbrown "0.14", which, by cargo's caret comparison rules, allows the minor version to vary to 0.15 where the API has changed. If Polars took a hashbrown dependency of "0.14.0", then only the patch version would be allowed to vary. I got things working again by downgrading indexmap in the cargo.lock: cargo update indexmap@2.6.0 --precise 2.5.0 |
I apologize, I'm somewhat of a novice when it comes to |
I'm not aware of a way to do so via the Cargo.toml. I'm also observing that my fix above doesn't always work-- cargo somehow still pulls down hashbrown 0.15 when building on other platforms/with cibuildwheel, and I can't seem to control it. |
I am having the same errors compiling |
Polars is using Yes, indexmap 2.6.0 updated to hashbrown 0.15, but polars will still be using its own hashbrown 0.14. |
Thanks, to recap, the temporary Cargo.toml fix, until the Polars crate is updated, is to add the following line to your dependencies: hashbrown = { version = "=0.14.5", features = ["raw"] } |
The precise "=0.14.5" pinning shouldn't be necessary, but that's likely to be the last 0.14 release anyway. The important part is to add the "raw" feature. |
Try to get the fix for pola-rs/polars#19063 in a better way to fix CI
* fetch extension name and version from env variable * set error message * fix: Support boolean lists * test: Add boolean list roundtrip test * Fix link formatting in CONTRIBUTING.md * derive Debug for Savepoint * Use ptr::write when writing uninitialized memory * Use smaller unsafe blocks * Rust BindData/InitData can just use Rust types * Use unsafe blocks inside unsafe fns generated by macro This will prevent the macro generating a warning in edition 2024 * Fix unused import * Better safety docs for vtab methods Contrary to the previous docs, the instances passed to these functions are *not* initialized by the caller. Rather, the called function is responsible for writing into uninitialized memory. * Similar safety fixes in vtab tests * Update pola-rs Try to get the fix for pola-rs/polars#19063 in a better way to fix CI * Remove pola-rs workaround * Upgrade arrow-rs to 54 * Fix test to trigger append error * update to 1.2.0 * update polars again * reexport polars-arrow, fix lifetime clippy * upgrade sources, bindgen * remove polars from default * uh update source again? * upgrade bindgen * limit bindgen * allow unsatble/deprecated c api for now * format that shidd * install openssl * ok, update it and if it doesnt work we're getting rid of it * yeet * remove asan for now * adjust timestamp tests for utc * fix logicaltypeid export * format * add logicaltypeid export again --------- Co-authored-by: Sam Ansmink <samansmink@hotmail.com> Co-authored-by: peasee <98815791+peasee@users.noreply.github.com> Co-authored-by: Alex Kesling <alex@kesling.co> Co-authored-by: Zheyu Shen <arsdragonfly@gmail.com> Co-authored-by: Martin Pool <mbp@sourcefrog.net> Co-authored-by: John Allen <john@threedogconsulting.com> Co-authored-by: nm <55702585+bnmoch3@users.noreply.github.com>
Checks
Reproducible example
Log output
Issue description
Trying to recreate this example from the user guide when I ran into this issue.
Expected behavior
polars-core
should build a MWE with thedtype-categorical
flag enabled.Installed versions
dtype-categorical
The text was updated successfully, but these errors were encountered: