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

feat: TOML Support #128

Open
aggieben opened this issue Apr 13, 2019 · 2 comments
Open

feat: TOML Support #128

aggieben opened this issue Apr 13, 2019 · 2 comments

Comments

@aggieben
Copy link
Contributor

Description

I'm interested in TOML support in Argu, and I may be able to submit a PR for it, but I wanted to open this issue to get some feedback about interest from the maintainers, as well as suggestions regarding how to go about it.

If a PR for this would be welcomed, the main question I have is with regard to how to handle third-party dependencies (I think https://github.com/xoofx/Tomlyn looks good for this).

Would it be acceptable to just take the dependency directly, and then it would ship with Argu everywhere, or would we want to build support in a separate assembly that would have to be an additional Nuget dependency in a client project?

Any other feedback on this would be welcome.

@bartelink
Copy link
Member

Good that you thought of and raised the dependency issue: No for adding a dependency to Argu please - you have no idea how many things use Argu and the constraint will likely yield a better design in any case (i.e. allow other pluggable parsers)

I think if you can expose the extensibility point you need to build it separate it's likely a good thing - even if the impl ultimately ends up living in the same repo (though a consumer driven contract in the form of a test or two should be enough?), it should be a separate DLL and NuGet.

@bartelink
Copy link
Member

There are active maintainers now, and an easy release mechanism, so getting an impl out the door would not be a problem now...

Main constraint/assumption would be that the impl would be in a separate project to isolate the deps

Figuring out a more general way to plug in arbitrary readers (and composing argument-level help about whether/how an arg can be represented in a given source) is kinda the elephant in the room too, see #171 and #143

@bartelink bartelink changed the title TOML Support feat: TOML Support Dec 14, 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

2 participants