Open FraMecca opened 5 years ago
Suggestion: You might want to consider including a generic backend interface for config info. So that the config data specification is/can be decoupled from the source of the config information. The config info can then be provided by / stored in several/multiple formats like commandline args, ini file, json, xml, yaml, database (sql, nosql), ldap, directory structure, fuse, etc. It might even allow the user to freely choose the desired config backend and convert between them if/when necessary.
reference #22 reference #21
I agree with @dkgroot about having a generic and extensible library for app configuration. For an example of such API, check https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-2.2.
If you write your own backend impl and follow the definition it can/should be used by any/everyone. The interface requirements would have to provide for minimal and extended requirements. Some backend formats might not able to do everything the others can do. For example standard ini files don't have a concept of includes, arrays/maps (like json), or references (like yaml/xml).
Also please add: https://github.com/burner/inifiled to the list :-)
You can see this project: https://github.com/huntlabs/hunt-console
Take a look at this CLI package for Golang: https://github.com/urfave/cli/blob/master/docs/v2/manual.md
@greenduck exactly what I had in mind. This project could be renamed: Port go cli library to D.
The only difference would be the fact that D could accomplish more at compile time and could use pegged in a lot of places where the go cli library do parsing at runtime.
Hi! I've been learning the D language and recently came across SAoC. I have some experience in PL-development (with C++) and have worked on the Pallene compiler with GSoC before (C/Lua). I want to try my hand at this issue (seeing it hasn't been closed yet).
Since it's been a while and this issue hasn't received a lot of activity, would it be fair to assume that this problem is still open to contribution?
I've worked with/on arg-parsers before and have a braindump I wanted to post, thought I should ask first.
Cheers!
thank you for taking in interest. Maybe have a look at the modules in D's standard library phobos https://dlang.org/phobos/index.html and the community packages in code.dlang.org.
We already have a couple of command line argument parsers, so we are properly good on that front, but having a structured view at what other lang/OSs/libs can do and what D already can will every likely shows things that can be improved.
Thanks for the heads up! I'll take a look at those ^^
Description
The aim of this project is to create a library that aids in the development of command line applications in unix systems, mainly providing a unified interface for:
There are many specifications for cli arguments such as:
Moreover common command line utilities adhere to freedesktop specifications for storing and accessing user data and configurations:
There are already some experiments in this space, mainly:
Even if some of these libraries try to unify command line parsing and configuration file parsing, they either don't adhere to specifications or are not fully compliant. Moreover some cli utilities could take into consideration environment variables
This library should provide a unified api to parse configuration files from standard locations, environment variables and cli arguments (in this order). Moreover the library could provide support to multiple file configurations format (sdl, yaml, toml, etc...) and standardized system locations.
What are rough milestones of this project?
To be discussed
How does this project help the D community?
This project helps the D community by providing an higher level api than std.getopt and fulfills the common needs of developers that build cli utilities for unix systems.
Recommended skills
Knowledge of the GNU/Linux operating system, shell and common cli utilities.
Point of Contact
@FraMecca
References
See above links
<NG discussions, GitHub PRs, Bugzilla issues, ...>