[GH-ISSUE #1382] Avoid using default features of dependencies

kerem commented

2026-02-27 19:31:38 +03:00

Owner

Originally created by @kingosticks on GitHub (Oct 25, 2024).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1382

Is your feature request related to a problem? Please describe.
I'm unable to control (disable) unneeded features of librespot's dependencies when pulling librespot (as a library) into other projects. A particular example is rustls which librespot compiles with the default feature set e.g. logging enabled and using aws-lc-sys instead of the more lightweight ring alternative.

Describe the solution you'd like
I've read that libraries should avoid enabling default features of their dependencies and enable only what's required. Anything optional should be passed through for the caller to control. You can see this in libraries like ureq and hyper-rustls. From https://github.com/algesten/ureq/issues/765#issuecomment-2218703792

I think our guidance for libraries like ureq is to take rustls as a dependency with no default features enabled, and then let consumers either take their own direct dep on rustls to activate a specific feature flag for a backend, or to have ureq expose its own optional features that enable the relevant rustls features. That's the model hyper-rustls uses as one example.

But I appreciate we want to keep the librespot binary easy to use. So maybe we need to think about separating the deps of the library and the binary. The library wants to provide options, the binary is a concrete example of a particular set of options.

Additional context
I think if we did this we could then consider switching to using ring as the default cryptography implementation. I don't believe we have any actual requirement for using aws-lc and it's harder to build on some platforms.

Originally created by @kingosticks on GitHub (Oct 25, 2024). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1382 **Is your feature request related to a problem? Please describe.** I'm unable to control (disable) unneeded features of librespot's dependencies when pulling librespot (as a library) into other projects. A particular example is `rustls` which librespot compiles with the default feature set e.g. `logging` enabled and using `aws-lc-sys` instead of the more lightweight `ring` alternative. **Describe the solution you'd like** I've read that libraries should avoid enabling default features of their dependencies and enable only what's required. Anything optional should be passed through for the caller to control. You can see this in libraries like ureq and hyper-rustls. From https://github.com/algesten/ureq/issues/765#issuecomment-2218703792 > I think our guidance for libraries like ureq is to take rustls as a dependency with no default features enabled, and then let consumers either take their own direct dep on rustls to activate a specific feature flag for a backend, or to have ureq expose its own optional features that enable the relevant rustls features. That's the model hyper-rustls uses as one example. But I appreciate we want to keep the librespot binary easy to use. So maybe we need to think about separating the deps of the library and the binary. The library wants to provide options, the binary is a concrete example of a particular set of options. **Additional context** I think if we did this we could then consider switching to using ring as the default cryptography implementation. I don't believe we have any actual requirement for using aws-lc and it's harder to build on some platforms.

kerem

2026-02-27 19:31:38 +03:00

closed this issue
added the
dependencies
label

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 26, 2024):

Guess no one can object to that. What would be the best way to do that? Do we need to resurrect librespotd, or do we make a separate workspace here?

Also I agree on using ring instead of aws-lc again. FIPS would be the only reason right? That wouldn't matter.

We should also take another look at needing both ring and rustls. I remember one didn't have AES192 anymore and the other... I forgot.

@roderickvd commented on GitHub (Oct 26, 2024): Guess no one can object to that. What would be the best way to do that? Do we need to resurrect librespotd, or do we make a separate workspace here? Also I agree on using ring instead of aws-lc again. FIPS would be the only reason right? That wouldn't matter. We should also take another look at needing both ring and rustls. I remember one didn't have AES192 anymore and the other... I forgot.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@kingosticks commented on GitHub (Oct 26, 2024):

I think we can just shuffle things about a bit and more or less keep things as they are. That's what I'll attempt to do, at least.

And yes, I think it's mostly just FIPS. I think most projects are choosing to not use the new default.

@kingosticks commented on GitHub (Oct 26, 2024): I think we can just shuffle things about a bit and more or less keep things as they are. That's what I'll attempt to do, at least. And yes, I think it's mostly just FIPS. I think most projects are choosing to not use the new default.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@pstumpf commented on GitHub (Dec 4, 2024):

May I ask what the holdup is on this diff? This would allow several spotify packages to get updated on OpenBSD …

@pstumpf commented on GitHub (Dec 4, 2024): May I ask what the holdup is on this diff? This would allow several spotify packages to get updated on OpenBSD …

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@fivebanger commented on GitHub (Dec 5, 2024):

I have merged the changes from github.com/kingosticks/librespot@24bbc6314c into my code, based on v0.6.0 release. I'm running librespot + changes without any issue. I'm using default features, compiled for Windows, PC/Linux and RPi, 32bit and 64bit (all native builds, no cross-compiling). I really appreciate to not run into build issues related to aws-lc-sys (even though all my systems are also prepared for building with aws-lc-sys).

@fivebanger commented on GitHub (Dec 5, 2024): I have merged the changes from https://github.com/kingosticks/librespot/commit/24bbc6314c991c64d1846162f739f223c44e5779 into my code, based on v0.6.0 release. I'm running librespot + changes without any issue. I'm using default features, compiled for Windows, PC/Linux and RPi, 32bit and 64bit (all native builds, no cross-compiling). I really appreciate to not run into build issues related to `aws-lc-sys` (even though all my systems are also prepared for building with `aws-lc-sys`).

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@jirutka commented on GitHub (Apr 28, 2025):

I’m maintainer of the spot package in Alpine Linux that uses librespot. I just wanted to upgrade the package to 0.5.0 and run into the issue with aws-lc-sys. I checked its dependency tree and I’m horrified – librespot brings an incredible dependency bloat. I’m really tired of this shit – dependency bloat in Rust projects caused by irresponsible approach to dependencies and the default-features antipattern. And cargo makes it extremely hard to fix this mess in downstream. So I’m strongly considering removing the spot package.

@jirutka commented on GitHub (Apr 28, 2025): I’m maintainer of the [spot](https://github.com/xou816/spot) package in Alpine Linux that uses librespot. I just wanted to upgrade the package to 0.5.0 and run into the issue with aws-lc-sys. I checked its dependency tree and I’m horrified – librespot brings an incredible dependency bloat. I’m really tired of this shit – dependency bloat in Rust projects caused by irresponsible approach to dependencies and the default-features antipattern. And cargo makes it extremely hard to fix this mess in downstream. So I’m strongly considering removing the spot package.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@roderickvd commented on GitHub (Apr 28, 2025):

Everybody agrees with getting rid of aws-lc-sys and default features. You can help if you want.

@roderickvd commented on GitHub (Apr 28, 2025): Everybody agrees with getting rid of `aws-lc-sys` and default features. You can help if you want.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

Moved away from AWS-LC to ring in fe7ca0d700.

@roderickvd commented on GitHub (Aug 13, 2025): Moved away from AWS-LC to ring in fe7ca0d7009c59d3189d1682154ad63a8fb71332.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@kingosticks commented on GitHub (Aug 13, 2025):

I'm a bit surprised this just works, I thought one of the lesser maintained rustls related packages didn't allow you to select provider so it ended up being stuck on aws. I can't remember which, I'll check (much) later. Good work though.

@kingosticks commented on GitHub (Aug 13, 2025): I'm a bit surprised this just works, I thought one of the lesser maintained rustls related packages didn't allow you to select provider so it ended up being stuck on aws. I can't remember which, I'll check (much) later. Good work though.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

Hopefully courtesy of all the upstream work. A fair number of dependencies were updated, certainly a lot of TLS related ones.

@roderickvd commented on GitHub (Aug 13, 2025): Hopefully courtesy of all the upstream work. A fair number of dependencies were updated, certainly a lot of TLS related ones.

kerem commented

2026-02-27 19:31:39 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

Let’s double check that beyond compiling, it also actually works. At least I can log in again.

@roderickvd commented on GitHub (Aug 13, 2025): Let’s double check that beyond compiling, it also actually works. At least I can log in again.

Rows
Columns

[GH-ISSUE #1382] Avoid using default features of dependencies #624