Skip to content
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

Avoid using default features of dependencies #1382

Open
kingosticks opened this issue Oct 25, 2024 · 4 comments
Open

Avoid using default features of dependencies #1382

kingosticks opened this issue Oct 25, 2024 · 4 comments

Comments

@kingosticks
Copy link
Contributor

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 algesten/ureq#765 (comment)

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.

@roderickvd
Copy link
Member

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.

@kingosticks
Copy link
Contributor Author

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 added a commit to kingosticks/librespot that referenced this issue Oct 29, 2024
kingosticks added a commit to kingosticks/librespot that referenced this issue Oct 29, 2024
kingosticks added a commit to kingosticks/librespot that referenced this issue Oct 29, 2024
@pstumpf
Copy link

pstumpf commented Dec 4, 2024

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

@fivebanger
Copy link
Contributor

I have merged the changes from kingosticks@24bbc63 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants