-
Notifications
You must be signed in to change notification settings - Fork 19
What's left for 0.1 #75
Hello All,
I'm wondering what remaining issues/discussions are gating the 0.1 release. I think that it will be good to get something out there soon to get feedback about the specification. The various CLI frameworks can start adding initial support for it, which can help and build a corpus of CLI descriptions. Clients can begin using those descriptions. The trouble right now is that there isn't the 0.1 tag on the specification for interoperability.
All reactions
Replies: 5 comments 5 replies
@cmcgee1024 Yes, I think it's time we move it forward as well so it can start being used.
What outstanding issues are needed for a 0.1 release? Or should we just take what we have and make it stable?
All reactions
@patriksvensson imo there's nothing major that's blocking getting v0.1 out. I have a draft PR for swift-argument-parser that's not perfect, but probably good enough to start getting feedback and building out a corpus of OpenCLI examples. I would like to see if we can get some convergence on #46 , even if it's informal for now to coincide with 0.1. There's active discussion, and progress being made.
All reactions
@cmcgee1024 Is there an email I can reach you on? I'm trying to setup some kind of steering group with more people than myself, and would love to have you (and other maintainers of CLI tools) in it.
All reactions
@patriksvensson I have a Mastodon attached to my profile. Does that work?
All reactions
That will work!
All reactions
I think there are some thing issues that came up in discussion #63 that might benefit from discussion.
Here are the ones that I think would be good to decide on before cutting version:
(削除) 1. Key value separator for options. Some tools require spaces, = , colon, etc (削除ここまで) (although we may want to have it be an array in conventions so if a command supports both = and ' ', it would be specififed. This was brought up in #78 )
2. Default Values for options, as what does the tool use if no arg is given to an option (kubectl defines in their usage --no-headers=false)
3. It would be useful to be able to specify that common use of -- which often detones the end of the parsing by the given command and everything after it is given to so other command. For example kubectl exec -it transform-nifi-0 -c metrics -n dev -- /bin/sh -c "cat /etc/hosts" I'm not totally sure what a good way to do this in the opencli spec but it is commonly used.
4. (削除) Also, it would be very useful if the spec could specify what versions of the target tool it correctly spec. (削除ここまで) (again we may want a way to represent multiple version for at least two cases: a tool has multiple version that are CLI api identical and for cases where two providers provide a API compatible tool (think posix compatible tools).
All reactions
Also, I would say that we should decide on #70. Because as someone that has actually implemented code against this spec, it is awkward to have to implement a Document case and Command case, and them being basically identical. I don't know that I agree with his solution but I think we could do better and it will be a breaking change. (I'll put my proposal in the discussion).
All reactions
+1s to @cmcgee1024 & @devin-fisher. From my POV, #46 is required and #70 is highly desirable for a 0.1.
All reactions
@patriksvensson I'm wondering what your thoughts are or how we can keep the conversation moving forward?
All reactions
I haven't had time the last couple of days, and I want to sit down and read it through properly. Will try to get to it tonight. Sorry for being unresponsive on this!