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

Refactor Config structs according to features #800

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

CPerezz
Copy link
Contributor

@CPerezz CPerezz commented Jan 31, 2021

As it was stated in #394, structs like SharedConfigValues or
SpotifydConfig contain fields like mixer, control and device
which only apply if alsa-backend feature is enabled.

Therefore, it would be nice if these fields were only documented when
the feature is enabled as well as used.

Closes #394

As it was stated in Spotifyd#349, structs like `SharedConfigValues` or
`SpotifydConfig` contain fields like `mixer`, `control` and `device`
which only apply if `alsa-backend` feature is enabled.

Therefore, it would be nice if these fields were only documented when
the feature is enabled as well as used.

Closes Spotifyd#349
src/config.rs Outdated
@@ -494,28 +505,52 @@ impl SharedConfigValues {
}
}

cfg_if::cfg_if! {
Copy link
Contributor

@robinvd robinvd Feb 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this might work as well (and be nicer)

merge!(general fields)

#[cfg(alsa)]
merge!(alsa fields)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. That's a good one.

Copy link
Contributor

@robinvd robinvd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

im not completely sure if changing the config layout like this is a breaking change or not.

Cargo.toml Show resolved Hide resolved
@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 8, 2021

im not completely sure if changing the config layout like this is a breaking change or not.

I think so. Basically when you're now setting None for these config options, you should directly not specify them or some similar thing. I'd need to check if the configfiles parsing behaves on a friendly way with this. If not, I'll need to refactor this code too.

If it's done by clap or some similar crate, then once compiled that will be handled automatically, otherways I'll need to edit also the configfile parsing.

Also will need to add docs for the different config options considering alsa and non-alsa features.

@robinvd
Copy link
Contributor

robinvd commented Feb 8, 2021

alright good to know, then we have to bump the version

@slondr slondr added this to the v0.4.0 milestone Feb 8, 2021
@slondr
Copy link
Member

slondr commented Feb 8, 2021

We already have another MR that's "waiting" on 0.4 to be merged, we can add this one to the list.

Maybe we should make version branches to keep track?

@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 8, 2021

So the macro stuff has been already addressed. And tested.

I'm just concerned about one thing regarding the SpotifyConfig struct.

Should the alsa_backend-only fields be Option<T> or just T? Since as the issue mentions, they need to be expressed if the feature is set.

I made the refactor having the fields like:

#[cfg(feature = "alsa-backend")]
    pub(crate) audio_device: String,
    #[cfg(feature = "alsa-backend")]
    pub(crate) control_device: String,
    #[cfg(feature = "alsa-backend")]
    pub(crate) mixer: String,

But I can change them to be Option<String>.

Once this is clarified, It might need to be specified in the mdbook a bit more clearly IMO. Then the PR will be ready I think.

@CPerezz CPerezz requested a review from robinvd February 8, 2021 22:29
@robinvd
Copy link
Contributor

robinvd commented Feb 8, 2021

If it is a plain string, and i specify it in the config but not command line will it then fail?

@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 8, 2021

If it is a plain string, and i specify it in the config but not command line will it then fail?

Exactly! Good point! Let's make it an Option as it was in the beginning, I thought it was like this due to the backend possibilities but it's also because of being a config param that can be missing too.

In the wiki mdbook it's not stated clearly that the config
options that refer to `mixer`, `controller` and `device` can
be directly commented out since they're only used when
spotifyd is compiled with `alsa_backend` feature.
@CPerezz CPerezz requested a review from mainrs February 8, 2021 23:44
@robinvd
Copy link
Contributor

robinvd commented Mar 3, 2021

I think this looks good! And we should release this in the next breaking change!

@mainrs
Copy link
Member

mainrs commented Mar 27, 2021

The breaking change concern could be addressed by explicitly telling serde to ignore unknown fields. I do remember there was a way but I can't write it down off the top of my head.

@mainrs
Copy link
Member

mainrs commented Mar 27, 2021

So the macro stuff has been already addressed. And tested.

I'm just concerned about one thing regarding the SpotifyConfig struct.

Should the alsa_backend-only fields be Option<T> or just T? Since as the issue mentions, they need to be expressed if the feature is set.

I made the refactor having the fields like:

#[cfg(feature = "alsa-backend")]
    pub(crate) audio_device: String,
    #[cfg(feature = "alsa-backend")]
    pub(crate) control_device: String,
    #[cfg(feature = "alsa-backend")]
    pub(crate) mixer: String,

But I can change them to be Option<String>.

Once this is clarified, It might need to be specified in the mdbook a bit more clearly IMO. Then the PR will be ready I think.

I do remember that spotifyd also had a default option that, when no config is supplied, it uses the Default implementation. Setting this to String would break it, as the CLI wouldn't work without the configuration values.

This is something we could (and I think even should!) consider for a large breaking change at some point. I'd rather have mandatory fields than some magic that works in the background (and not even on all machines) .

@CPerezz
Copy link
Contributor Author

CPerezz commented Apr 26, 2021

Sorry @sirwindfield but this got lost between tons of notifications. The attributes you mention are indeed Option<String> so I'm unsure if this needs any refactoring before it can be approved/landed.

@stale
Copy link

stale bot commented Jul 25, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix Issues that will not be fixed under any circumstances label Jul 25, 2021
@stale stale bot closed this Aug 4, 2021
@CPerezz
Copy link
Contributor Author

CPerezz commented Aug 24, 2022

@mainrs @robinvd is this something that is still not desired?

Copy link
Member

@eladyn eladyn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know if it's worth commenting on this PR, but if there is still interest from the maintainer side, the below can be taken into consideration.

global_section.mixer = "PCM1".to_string();

// The test only makes sense if both sections differ.
assert!(spotifyd_section != global_section, true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assert!() tests by itself, whether the expression is true.

Suggested change
assert!(spotifyd_section != global_section, true);
assert!(spotifyd_section != global_section);

Comment on lines +456 to +466
cfg_if::cfg_if! {
if #[cfg(feature = "alsa_backend")] {
deb_struct
.field("device", &self.device)
.field("control", &self.control)
.field("mixer", &self.mixer)
.finish()
} else {
deb_struct.finish()
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By using the below variant, we could get rid of the cfg_if crate and the effect should be the same.

Suggested change
cfg_if::cfg_if! {
if #[cfg(feature = "alsa_backend")] {
deb_struct
.field("device", &self.device)
.field("control", &self.control)
.field("mixer", &self.mixer)
.finish()
} else {
deb_struct.finish()
}
}
#[cfg(feature = "alsa_backend")]
{
deb_struct
.field("device", &self.device)
.field("control", &self.control)
.field("mixer", &self.mixer);
}
deb_struct.finish()

#[test]
fn test_section_merging() {
let mut spotifyd_section = SharedConfigValues::default();
global_section.mixer = "PCM".to_string();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
global_section.mixer = "PCM".to_string();
spotifyd_section.mixer = "PCM".to_string();

Comment on lines +774 to +775
// Add the new field to spotifyd section.
spotifyd_section.mixer = "PMC".to_string();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be necessary, right?

@@ -738,4 +752,27 @@ mod tests {
spotifyd_section.username = Some("testUserName".to_string());
assert_eq!(merged_config, spotifyd_section);
}

#[cfg(features = "alsa_backend")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#[cfg(features = "alsa_backend")]
#[cfg(feature = "alsa_backend")]


#[cfg(features = "alsa_backend")]
#[test]
fn test_section_merging() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be renamed.

let mut mixer = {
// We just need to initialize the mixer. The contents will be mutated for sure
// and therefore we don't need to worry since all of the branches are covered.
let mut mixer: Box<dyn FnMut() -> Box<dyn Mixer>> = unimplemented!();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will panic, if run. You can just omit the = ... part.

Comment on lines +144 to 155
#[cfg(feature = "alsa_backend")]
audio_setup: main_loop::AudioSetup {
mixer,
backend,
audio_device: config.audio_device,
},
#[cfg(not(feature = "alsa_backend"))]
audio_setup: main_loop::AudioSetup {
mixer,
backend,
audio_device: config.audio_device.clone(),
audio_device: None,
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#[cfg(feature = "alsa_backend")]
audio_setup: main_loop::AudioSetup {
mixer,
backend,
audio_device: config.audio_device,
},
#[cfg(not(feature = "alsa_backend"))]
audio_setup: main_loop::AudioSetup {
mixer,
backend,
audio_device: config.audio_device.clone(),
audio_device: None,
},
audio_setup: main_loop::AudioSetup {
mixer,
backend,
#[cfg(feature = "alsa_backend")]
audio_device: config.audio_device,
#[cfg(not(feature = "alsa_backend"))]
audio_device: None,
},

Comment on lines +26 to +28
// We need to allow these lints since the conditional compilation is
// what makes them appear.
#[allow(unused_must_use, unreachable_code, unused_variables)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least with the changes below and on Rust 1.63, none of those should be necessary any more.

@mainrs
Copy link
Member

mainrs commented Aug 26, 2022

Hello! I do not have the time to maintain the project actively right now. I think it would still be a good idea to get this PR done, since it just does not make sense to have them in the same struct.

The current code base of spotifyd feels more like patch work then anything else to be honest. The tokio 1.0 rewrite did help though. I definitely am interested in seeing how librespot does these days. Maybe some changes allow us to make the whole client more lightweight in general. Or restructure some features/code modules all together.

I'll definitely investigate this. I cannot tell you when though.

@CPerezz
Copy link
Contributor Author

CPerezz commented Aug 29, 2022

Thanks for the review comments @eladyn

Will wait to see if @mainrs has more time in the future and address this.

Thank you all! :)

@slondr slondr reopened this Aug 30, 2022
@eladyn eladyn removed the wontfix Issues that will not be fixed under any circumstances label Sep 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add documentation to configuration fields that are not allowed under some circumstances
5 participants