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

Release 1.0 #8

Open
3 tasks
dbaelz opened this issue Oct 15, 2018 · 6 comments
Open
3 tasks

Release 1.0 #8

dbaelz opened this issue Oct 15, 2018 · 6 comments
Assignees
Labels
question Further information is requested
Milestone

Comments

@dbaelz
Copy link
Owner

dbaelz commented Oct 15, 2018

I'd like to release a version 1.0 in the near future. In this issue I want to collect open questions, missing features and further points which should be done by then. Feel free to add them as comments and I'll expand the list when necessary.

TODO

@dbaelz dbaelz added the question Further information is requested label Oct 15, 2018
@dbaelz dbaelz added this to the Release 1.0 milestone Oct 15, 2018
@dbaelz dbaelz self-assigned this Oct 15, 2018
@dbaelz
Copy link
Owner Author

dbaelz commented Oct 15, 2018

@DrewCarlson Any suggestions for the 1.0 release? Do you think the library is feature-ready for this step?

@DrewCarlson
Copy link
Contributor

I do have a couple of feature and API suggestions to run by you, I will comment them here once I get a chance to think through them today. Most of the things I've considered adding would work best as additional modules we could add after v1 (ex. cross platform readline, getpass, etc. to eliminate the need for this and better support all platforms).

I'm trying to get another project down from 3 CI services to just Travis, if I get Windows working I'll open a PR here.

PS: It is just a demo project (that is totally insecure at the moment), but the Kryptor project I linked could be a good reference project once windows and linux is configured.

@dbaelz
Copy link
Owner Author

dbaelz commented Oct 15, 2018

@DrewCarlson Thanks or all your help, PRs and ideas. I'm currently a little bit busy at work and in my private time so "near future" for the 1.0 release might be an exaggeration. More like early to mid November.

I'll take a look on the kotlin-mobius and Kryptor projects and think about the 1.0 feature set by myself. Just add your ideas for (pre) 1.0 features in the comments and we could discuss them here or by mail/chat.

@DrewCarlson
Copy link
Contributor

👌 Sounds good! No rush on releasing, publishing manually is easy. You're very welcome, Konclik has saved me a lot of time :).

@DrewCarlson
Copy link
Contributor

DrewCarlson commented Oct 15, 2018

Here are some of the more important things I’d like to see for v1

  • Add VarArgument with optional arg count, can only be first or last in the arguments list.
  • Support option aliases: Parameter.Option.Value("--times”, “-t”)
  • Allow Options to have help text

Another thing I think would be great (though it could wait until after v1) is support for providing a mechanism for precisely typed arguments with verified properties. Ex. you could define a set of arguments like listOf(FileArgument(‘input’, exists = true), FileArgument(‘output’, folder = true)) and during argument parsing, input would be validated as a file/file path and that it exists and output would be validated to be a folder on the system. or a valid folder path.

I'm not saying to add a whole bunch of argument types right now, but it would be worth figuring out the impact on the api when supporting these specialized arguments.

EDIT: Also now may be a good time to test dokka with the new MPP plugin.

@dbaelz
Copy link
Owner Author

dbaelz commented Oct 16, 2018

For the 1.0 release

  • Support for abbreviations and help pages for parameters was in my mind as well. Help should be easy, abbreviation is more work but doable.
  • VarArgument is an interesting idea. I'll open an issue for this in the future, so we could discuss details
  • Dokka: Yeah, the library is lacking some code documentation and I'll do it before the 1.0 release

Future

  • I thought about the challenge to provide the type parameter for the options so that the default value and the parsed args has the correct type are not Strings. The bad side: Type erasure, generics, (in|co)variance and so on. I'm not sure if it's done that easy and without changing everything. Maybe something for a 2.0, maybe earlier 😀
  • I'll keep your post 1.0 ideas in mind. Special handling for files is another cool thing for CLI applications and I'm open minded for new/other positional arguments and options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants