[PR #1227] [CLOSED] Cargo replace hex with faster-hex #1289

New issue

Closed

opened 2026-02-27 20:01:53 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:01:53 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/1227
Author: @dsheets
Created: 12/1/2023
Status: ❌ Closed

Base: dev ← Head: cargo-replace-hex-with-faster-hex

📝 Commits (2)

da3b353 Replace the apparently unmaintained hex crate with faster-hex
5029c4e spclient: improve token request logging

📊 Changes

5 files changed (+38 additions, -18 deletions)

View changed files

📝 Cargo.lock (+11 -2)
📝 Cargo.toml (+1 -1)
📝 core/Cargo.toml (+1 -1)
📝 core/src/spclient.rs (+23 -13)
📝 src/main.rs (+2 -1)

📄 Description

Hi, long time listener, first time caller...

I'm doing some work on the spotify_id module for another project including replacing the bespoke hex encode/decode there with a library call and I started using hex because it is a dependency of both librespot and librespot-core already... but hex doesn't appear to be maintained and it lacks really obvious stuff like symmetry between its traits and its functions and major performance issues (that we admittedly don't really care about here, yet).

Anyway, looking around crates.io, I came across faster-hex which is still far from perfect but the maintainers seem active and likely responsive. So I patched librespot and librespot-core to use it instead.

Unfortunately, I couldn't work out how to test the hashcash challenge. I tried changing my OS but that either crashes (for "android") or fails with 400 (for "ios"). I included the improved logging I added to try to understand these issues.

If you could review the changes and let me know how to test the hashcash challenge (or test it yourself or confirm that LGTY), I would be grateful. I will be sending along my spotify_id refactoring changeset soon.

Thanks!

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/1227 **Author:** [@dsheets](https://github.com/dsheets) **Created:** 12/1/2023 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `cargo-replace-hex-with-faster-hex` --- ### 📝 Commits (2) - [`da3b353`](https://github.com/librespot-org/librespot/commit/da3b3539a87c78915be800fe11ef3de5863ec252) Replace the apparently unmaintained hex crate with faster-hex - [`5029c4e`](https://github.com/librespot-org/librespot/commit/5029c4ed23aaff078cbd2a18709cfc923d80c725) spclient: improve token request logging ### 📊 Changes **5 files changed** (+38 additions, -18 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+11 -2) 📝 `Cargo.toml` (+1 -1) 📝 `core/Cargo.toml` (+1 -1) 📝 `core/src/spclient.rs` (+23 -13) 📝 `src/main.rs` (+2 -1) </details> ### 📄 Description Hi, long time listener, first time caller... I'm doing some work on the `spotify_id` module for another project including replacing the bespoke hex encode/decode there with a library call and I started using `hex` because it is a dependency of both `librespot` and `librespot-core` already... but `hex` doesn't appear to be maintained and it lacks really obvious stuff like symmetry between its traits and its functions and major performance issues (that we admittedly don't really care about here, yet). Anyway, looking around `crates.io`, I came across `faster-hex` which is still far from perfect but the maintainers seem active and likely responsive. So I patched `librespot` and `librespot-core` to use it instead. Unfortunately, I couldn't work out how to test the hashcash challenge. I tried changing my `OS` but that either crashes (for `"android"`) or fails with 400 (for `"ios"`). I included the improved logging I added to try to understand these issues. If you could review the changes and let me know how to test the hashcash challenge (or test it yourself or confirm that LGTY), I would be grateful. I will be sending along my `spotify_id` refactoring changeset soon. Thanks! --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>