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

Library for unix command line tools #30

Open
FraMecca opened this issue May 11, 2019 · 9 comments
Open

Library for unix command line tools #30

FraMecca opened this issue May 11, 2019 · 9 comments

Comments

@FraMecca
Copy link

FraMecca commented May 11, 2019

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:

  • parsing command line flags and arguments
  • parsing environment variables
  • parsing configuration files
  • accessing standard locations for configuration files and user data

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, ...>

@dkgroot
Copy link
Contributor

dkgroot commented May 11, 2019

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

@PetarKirov
Copy link
Member

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.

@dkgroot
Copy link
Contributor

dkgroot commented May 11, 2019

  • config Interface definition -> in the standard (phobos)
  • reference implementation -> in the standard (phobos)
  • other implementations can start outside and might mature into phobos later on.

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 :-)

@zoujiaqing
Copy link

You can see this project:
https://github.com/huntlabs/hunt-console

@greenduck
Copy link

Take a look at this CLI package for Golang:
https://github.com/urfave/cli/blob/master/docs/v2/manual.md

@FraMecca
Copy link
Author

FraMecca commented May 12, 2020

@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.

@srijan-paul
Copy link

srijan-paul commented Jul 27, 2021

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!

@burner
Copy link
Member

burner commented Jul 27, 2021

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.

@srijan-paul
Copy link

Thanks for the heads up!
I'll take a look at those ^^

@RazvanN7 RazvanN7 removed the gsoc2020 label Feb 3, 2023
@RazvanN7 RazvanN7 removed the saoc label Jul 10, 2023
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

8 participants