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

Configuration file #101

Open
KSXGitHub opened this issue May 3, 2019 · 12 comments
Open

Configuration file #101

KSXGitHub opened this issue May 3, 2019 · 12 comments

Comments

@KSXGitHub
Copy link
Contributor

KSXGitHub commented May 3, 2019

Summary

Right now, the only way to "configure" miniserve is via command-line arguments

miniserve --interfaces ::1 --port 8080 --auth user:sha256:hash $@

But it would be more convenient to have a global configuration file for recurring command-line options

# manifest version, it allows us to warn users when a breaking change is introduced
version: 0

# configuration values, almost identical to command-line arguments
config:
  interfaces: ['::1']
  port: 8080
  auth: 'user:sha256:hash'

Discussion

  • Which format should we use? RON, TOML or YAML?
  • Where to locate configuration files? ~/.miniserverc.$ext, ~/.miniserve/config.$ext, ~/.config/miniserve/config.$ext?
  • What to do when configuration file is invalid? Ignore, Warn, Error?
  • Which library should we use? (For now, I recommend serde)
@KSXGitHub
Copy link
Contributor Author

KSXGitHub commented May 3, 2019

@boastful-squirrel I do see your point, especially in a UNIX-like system: A UNIX program only does one thing and does it well. But not all systems are UNIX-like (Windows, obviously), and this tool is hardly an ideal UNIX program.

As for the advantage of configuration as opposed for alias/custom-commands: A configuration file is a data file and can be treated like data. It also works regardless of platform (aliases only work on POSIX shell, UNIX commands only works on UNIX-like system and .bat commands only works on Windows).

I also proposed #100, which, when combined with this feature, allows a system manager to easily manage users and passwords.

BTW, what is the "CTRL-R" that you referred to?

@ghost
Copy link

ghost commented May 3, 2019

It allows to search for commands in your bash history.

@KSXGitHub KSXGitHub mentioned this issue May 5, 2019
2 tasks
@svenstaro
Copy link
Owner

I have trouble deciding whether I want this or not. The general idea of miniserve is that it's a simple, basically braindead easy way of serving your files in a somewhat convenient way. It grew to allow auth and uploading and now it's supposedly growing to allow for multiple auth providers at the same time.

It's a logical consequence for it to gain config file support and honestly, at this point, I'm not sure that would exceed the complexity I had originally planned for miniserve. Don't get me wrong. I use miniserve in production myself in a big company and therefore it's certainly not just a toy project to me. However, the whole reason I made miniserve is that I wanted a simple tool without too much bloat.

I'm not saying no. I'm saying I'd appreciate some discussion on this.

@KSXGitHub
Copy link
Contributor Author

@svenstaro Then according to the UNIX philosophy™, miniserve should not have to handle any of this (including reading configuration file, authentication, themes), rather, there should be other helper programs that handle them for you:

  • Configuration file: A program that reads a config file and spawns miniserve with corresponding CLI flags. We don't have to change miniserve at all to support this.
  • Authentication: Miniserve should be able to rely on external program (or module) to do authentication (for example: miniserve --auth-cmd my-auth-program.sh). This way, miniserve will no longer be burdened with adding any authentication feature anymore. Of course, you must change miniserve to support this.
  • Themes: We should allow user to inject their own HTML code.

@svenstaro
Copy link
Owner

I'm not saying anything about UNIX philosophy. I'm not a minimalism purist. I'm a simplicity-loving pragmatist. I know that miniserve hardly adhere to UNIX principles.

@KSXGitHub
Copy link
Contributor Author

KSXGitHub commented May 6, 2019

@svenstaro Well, we can keep some existing feature out of convenient while also allow other programs (or modules) to extend miniserve's feature. What is great about UNIX philosophy is that it is infinitely extensible ("build program that works together") since every program is essentially a programmable function.

@svenstaro
Copy link
Owner

@boastful-squirrel I'd value your input on this. I know you already said you wouldn't use it but what do you think about this in the general context of this tool and what I said?

@ghost
Copy link

ghost commented May 7, 2019

@svenstaro if we keep it as simple as possible, aka something like this

interfaces = ["[::1]", "127.0.0.1"]
port = 9999
auth = ["foo:bar", "bip:bop"]
allow-upload = true
overwrite-files = true
default-color-scheme = "Archlinux"

then why not, it might be helpful for some people (is it worth it ? Only you can tell this :)) , especially the port configuration: some people might have another application running on 8080, so for those, they have to change the port everytime. I don't know how to handle it from the command line though. When no arguments are given, I expect miniserve to run with the default configuration (no auth, no upload, etc), not the one from the configuration file. I would probably make it explicit through an argument (--use-config or something). I would also warn the user that upload is set to true, even if it's in his configuration.

I would use toml for that, as the format is very simple.

@KSXGitHub
Copy link
Contributor Author

KSXGitHub commented May 7, 2019

Actually, now that I think about it, this feature isn't necessary, one can easily create a program that translates whatever configuration format they want into CLI arguments.

@svenstaro
Copy link
Owner

Ok so I had a proper long think and I agree we should have a very simple config file. I like the format proposed by @boastful-squirrel which seems to be TOML and since TOML and rust seem to go together a lot, let's use that. However, I think that we should use the config by default since that is what every other program does and it would be weird to deviate from that behavior. After all, if there is no config in place, it won't be used and there won't be a config in place without you knowing that since you have to put it in place specifically.

So, let's think about the implementation. I think the config should be searched in this order: ~/.config/miniserve/config.toml, /etc/miniserve/config.toml.
Can we auto-generate the config options from the StructOpt stuff we have in place? Would be neat and probably someone has already done that.

I don't want the config format to be visually nested (except for TOML lists) and I don't want it to have in-built versioning.

@KSXGitHub
Copy link
Contributor Author

Can we auto-generate the config options from the StructOpt stuff we have in place? Would be neat and probably someone has already done that.

You means using serde (toml-rs in particular)?

@svenstaro
Copy link
Owner

Yes, serde would be good for this.

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

No branches or pull requests

2 participants