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

Parse configuration file #101

Closed
wants to merge 12 commits into from
Closed

Parse configuration file #101

wants to merge 12 commits into from

Conversation

robinkrahl
Copy link
Collaborator

This patch series reads selected options (currently no_cache and model) from a
configuration file. This is only for discussion in #100. As I already
implemented it, I thought I might as well share it, even if we end up using a
different approach.

@d-e-s-o d-e-s-o self-assigned this Jan 25, 2020
@robinkrahl robinkrahl mentioned this pull request Jan 25, 2020
@d-e-s-o
Copy link
Owner

d-e-s-o commented Feb 1, 2020

Just to make sure, there is nothing you are waiting on from me here, correct @robinkrahl ?

@robinkrahl
Copy link
Collaborator Author

robinkrahl commented Feb 1, 2020 via email

@robinkrahl robinkrahl changed the title WIP: Parse configuration file Parse configuration file Feb 2, 2020
@robinkrahl
Copy link
Collaborator Author

I updated the pull request – I think it could be merged now.

I made these changes to the patch series:

  • Replace app_dirs with directories. app_dirs has not been updated for a while, and the author did not respond to my question regarding the maintenance status. By switching to directories, we lose access to system-wide configuration files, but we gain a more robust and better maintained dependency. (Problems with app_dirs include that it tries to create directories even if told not to, see get_app_dir creates directories despite the documentation saying otherwise andybarron/app-dirs-rs#34, and even if it supports system-wide configuration, it does not comply with the specification, see Consider doing something smarter with XDG multi-paths andybarron/app-dirs-rs#12).
  • Squash and re-order the commits to make the patch series more concise and to avoid unnecessary intermediate steps.
  • Add a --no-cache option for consistency.
  • Update the documentation and add an example file.
  • Add a simple unit test.

@d-e-s-o
Copy link
Owner

d-e-s-o commented Feb 3, 2020

Thank you, Robin. I hope to take a closer look tomorrow. I'll probably merge it if it looks alright. From my perspective, it mostly comes down to technical details that differentiate the solutions and I don't have the time to experiment with alternative approaches right now.

@robinkrahl robinkrahl closed this Feb 4, 2020
@robinkrahl robinkrahl deleted the config branch February 4, 2020 20:07
@d-e-s-o
Copy link
Owner

d-e-s-o commented Feb 5, 2020

Seems as if we are pulling in two version of arrayvec and now have a total of three mechanisms to deduce/do something based on the rustc version we work with.

@robinkrahl robinkrahl restored the config branch February 5, 2020 10:24
@robinkrahl
Copy link
Collaborator Author

Sorry, I did not mean to close this, I was just cleaning up old branches.

Seems as if we are pulling in two version of arrayvec

Ultimately, nom is to blame here as they use an old version of lexical-core, see rust-bakery/nom/pull/1100 and rust-bakery/nom/pull/1101. (The pull request would not fix this as it updates lexical-core to 0.6, but the arrayvec dependency is updated in 0.7.)

now have a total of three mechanisms to deduce/do something based on the rustc version we work with.

As far as I see, they are similar but not the same:

  • rustc_version provides functions that are evaluated at runtime.
  • rustversion provides macros for conditional compilation.

Which one is the third?

@robinkrahl robinkrahl reopened this Feb 5, 2020
Copy link
Owner

@d-e-s-o d-e-s-o left a comment

Choose a reason for hiding this comment

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

Publishing this review as GitHub doesn't allow me to comment otherwise. Comments may be stale & irrelevant but I didn't want them to get lost.


DeviceModel::from_str(v).map_err(|_| {
E::custom(format!(
"unexpected device model '{}', expected one of {}",
Copy link
Owner

Choose a reason for hiding this comment

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

If I am not mistaken this string is contained in the final error in a way that only the expected type/values should be contained. Need to double check.

pub no_cache: bool,
#[serde(default)]
Copy link
Owner

Choose a reason for hiding this comment

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

Nit: Move one line down.

@@ -11,6 +11,11 @@ Unreleased
- Added support for configuration files:
- Added `config` dependency in version `0.10.1`
- Added `serde` dependency in version `1.0.104`
- Reworked environment variables:
- Added the `NITROCLI_MODEL` and `NITROCLI_VERBOSITY` variables that set the
Copy link
Owner

Choose a reason for hiding this comment

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

"variables" -> "environment variables"?

@@ -37,9 +43,13 @@ pub struct Config {

impl Config {
pub fn load() -> Result<Self> {
let project_dirs = directories::ProjectDirs::from("", "", "nitrocli")
.ok_or_else(|| error::Error::from("Could not determine the home directory"))?;
Copy link
Owner

Choose a reason for hiding this comment

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

Lower case the error message for consistency?

@@ -37,9 +43,13 @@ pub struct Config {

impl Config {
pub fn load() -> Result<Self> {
let project_dirs = directories::ProjectDirs::from("", "", "nitrocli")
Copy link
Owner

Choose a reason for hiding this comment

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

Mind introducing named variables for the two empty string arguments? It's not really clear what they refer to otherwise. With "nitrocli" one can at least take a guess.


#[test]
fn config_file() {
let mut config = ::config::Config::new();
Copy link
Owner

Choose a reason for hiding this comment

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

Indentation too wide.

@d-e-s-o
Copy link
Owner

d-e-s-o commented Mar 30, 2020

Seems as if we are pulling in two version of arrayvec

Ultimately, nom is to blame here as they use an old version of lexical-core, see Geal/nom/pull/1100 and Geal/nom/pull/1101. (The pull request would not fix this as it updates lexical-core to 0.6, but the arrayvec dependency is updated in 0.7.)

Thanks for digging. I understand, but irrespective of who's fault it is, it's still not nice and something I'd really want to avoid.

now have a total of three mechanisms to deduce/do something based on the rustc version we work with.

As far as I see, they are similar but not the same:

  • rustc_version provides functions that are evaluated at runtime.
  • rustversion provides macros for conditional compilation.

Which one is the third?

version_check is what I was referring to.

In the next patch, we will implement configuration handling using the
config crate.  This patch adds a ConfigError variant to the Error struct
that wraps the config::ConfigError returned by the config crate.
This patch implements basic configuration handling that reads a
configuration file and stores the parsed data in the ExecCtx and RunCtx
structs.  It supports three configuration items:
- model (previously only --model)
- no_cache (previously only NITROCLI_NO_CACHE)
- verbosity (previously only --verbose)
To make parsing easier, we use serde to deserialize the configuration
data and store it in the Config struct.  As the default Deserialize
implementation for DeviceModel would only accept "Pro" and "Storage" and
the Enum! macro does not allow per-field attributes, we manually
implement Deserialize using the FromStr implementation.
This patch uses the config crate to parse the environment.  A variable
NITROCLI_KEY can be used to overwrite the configuration for *key*.  This
has the side effect that the NITROCLI_NO_CACHE variable is evaluated as
a boolean variable (instead of only checking whether it is set).  We
also accept two new variables, NITROCLI_MODEL and NITROCLI_VERBOSITY.
This patch uses the directories crate to query the appropriate path for
the configuration files.  For Linux, paths according to the XDG Base
Directory Specification are used.

Note that directories does not yet support the XDG_CONFIG_DIRS variable
for system-wide configuration files.  Therefore we only use a user
configuration file.
This patch adds a simple configuration file that demonstrates the syntax
and contains some documentation.  I suggest to ship this file together
with nitrocli and to install it e. g. in the  /usr/share/doc/nitrocli
directory.  This patch also adds a simple test case that makes sure that
the example file is parsed correctly.
This patch adds a new --no-cache option that corresponds to the
NITROCLI_NO_CACHE environment variable and the no_cache configuration.
This makes the user interface more consistent as all configuration items
are now backed by both an environment variable and a command-line
option.
This patch updates the man page for the last changes:
- new option --no-cache
- changes to the environment variables
- configuration files
@d-e-s-o
Copy link
Owner

d-e-s-o commented Aug 5, 2020

Just noticing the update. Is this the updated pull request ready for review already, Robin?

@robinkrahl
Copy link
Collaborator Author

robinkrahl commented Aug 5, 2020 via email

@d-e-s-o
Copy link
Owner

d-e-s-o commented Aug 5, 2020

No, I just rebased it onto the current devel. I’ll open a new PR with the new implementation so that you can compare both, okay?

Sounds good.

@d-e-s-o
Copy link
Owner

d-e-s-o commented Sep 2, 2020

We can probably close this pull request now that v2 has been merged.

@d-e-s-o d-e-s-o closed this Sep 2, 2020
@robinkrahl robinkrahl deleted the config branch September 10, 2020 22:36
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.

2 participants