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

Is docopt maintained? #371

Open
nilgoyette opened this Issue Mar 15, 2017 · 11 comments

Comments

Projects
None yet
7 participants
@nilgoyette

nilgoyette commented Mar 15, 2017

Sorry to create an issue for this but I don't know where else to ask.

  • 11 months without any activity on master, 28 PR waiting.
  • "The first release with stable API will be 1.0.0 (soon).", probably written more than one year ago.

We started using argparse again because docopt looks dead. This is sad. I want to know if docopt is still maintained to convince my boss that we can and should still use docopt! :)

@SeeSpotRun

This comment has been minimized.

Show comment
Hide comment
@SeeSpotRun

SeeSpotRun Mar 16, 2017

It seems the greater docopt is still alive (e.g. https://github.com/docopt/docopt.rs/commits/master)

SeeSpotRun commented Mar 16, 2017

It seems the greater docopt is still alive (e.g. https://github.com/docopt/docopt.rs/commits/master)

@antoineco

This comment has been minimized.

Show comment
Hide comment
@antoineco

antoineco Mar 23, 2017

We started using argparse again because docopt looks dead.

The usual reason is rather that the module doesn't meet your needs, not that it "looks dead" :) If there are blockers waiting for a review I think contacting the maintainers could help unlocking the situation.

Or maybe new maintainers could step in. @mboersma is fairly active on Github, maybe he knows how to proceed with docopt to get PR reviewed and merged.

antoineco commented Mar 23, 2017

We started using argparse again because docopt looks dead.

The usual reason is rather that the module doesn't meet your needs, not that it "looks dead" :) If there are blockers waiting for a review I think contacting the maintainers could help unlocking the situation.

Or maybe new maintainers could step in. @mboersma is fairly active on Github, maybe he knows how to proceed with docopt to get PR reviewed and merged.

@nilgoyette

This comment has been minimized.

Show comment
Hide comment
@nilgoyette

nilgoyette Mar 31, 2017

Thank you for your answers guys :) There's no PR I'm interested in and I don't need any particular update, I just needed to know if the project was going somewhere.

The lack of any official answer gives me the real answer though. I'll leave this issue open for the time being in case someone wonders too.

nilgoyette commented Mar 31, 2017

Thank you for your answers guys :) There's no PR I'm interested in and I don't need any particular update, I just needed to know if the project was going somewhere.

The lack of any official answer gives me the real answer though. I'll leave this issue open for the time being in case someone wonders too.

@SeeSpotRun

This comment has been minimized.

Show comment
Hide comment
@SeeSpotRun

SeeSpotRun Mar 31, 2017

@nilgoyette you can always try docpie which is very similar or click which is very different but still quite nice.

SeeSpotRun commented Mar 31, 2017

@nilgoyette you can always try docpie which is very similar or click which is very different but still quite nice.

@Xuanwo

This comment has been minimized.

Show comment
Hide comment
@Xuanwo

Xuanwo Apr 12, 2017

Same question here.

Xuanwo commented Apr 12, 2017

Same question here.

@keleshev

This comment has been minimized.

Show comment
Hide comment
@keleshev

keleshev Apr 20, 2017

Member

Docopt is really 99% perfect and doesn't need ongoing work. I simply don't have time to reject all those PRs with suggestions that come up again and again.

Still, I'm experimenting with Docopt improvements right now:

https://github.com/keleshev/docopt.ml

I really want to go that extra mile, that 1 last percent, before releasing version 1.0.0. I'm really aiming for 1.0.0 to be the last Docopt version. That last 1% will probably include:

  • Formal grammar,
  • Gorgeous, detailed error-messages, both for argv parsing and docstring parsing,
  • More powerful matching with non-finite automaton, (will handle cases like <args>... <last>),
  • Remove ARG convention in favor of <arg>,
  • Remove "unambiguous partial matching" rule (e.g. --ver matching --version),
  • Handle -- specially even if it is absent from the docstring,
  • Disallow dropping = for options with arguments in docstring (but not when parsing argv).

As you might have noticed, in 99% of cases the above changes do not matter, so you can happily continue using docopt as it is.

Member

keleshev commented Apr 20, 2017

Docopt is really 99% perfect and doesn't need ongoing work. I simply don't have time to reject all those PRs with suggestions that come up again and again.

Still, I'm experimenting with Docopt improvements right now:

https://github.com/keleshev/docopt.ml

I really want to go that extra mile, that 1 last percent, before releasing version 1.0.0. I'm really aiming for 1.0.0 to be the last Docopt version. That last 1% will probably include:

  • Formal grammar,
  • Gorgeous, detailed error-messages, both for argv parsing and docstring parsing,
  • More powerful matching with non-finite automaton, (will handle cases like <args>... <last>),
  • Remove ARG convention in favor of <arg>,
  • Remove "unambiguous partial matching" rule (e.g. --ver matching --version),
  • Handle -- specially even if it is absent from the docstring,
  • Disallow dropping = for options with arguments in docstring (but not when parsing argv).

As you might have noticed, in 99% of cases the above changes do not matter, so you can happily continue using docopt as it is.

@SeeSpotRun

This comment has been minimized.

Show comment
Hide comment
@SeeSpotRun

SeeSpotRun May 3, 2017

"Maintained" and "99% perfect" is comparing apples and oranges. Docopt is a great product but if it was well maintained then it wouldn't have 164 open Issues and 27 open Pull Requests.

I suggest that the Community should be helping @keleshev by taking a more active role in helping close out issues and PR's since he doesn't have enough time to do this. We can't close issues directly, but we should be able to give the OP's a satisfactory response and suggest that they close the issue themselves.

SeeSpotRun commented May 3, 2017

"Maintained" and "99% perfect" is comparing apples and oranges. Docopt is a great product but if it was well maintained then it wouldn't have 164 open Issues and 27 open Pull Requests.

I suggest that the Community should be helping @keleshev by taking a more active role in helping close out issues and PR's since he doesn't have enough time to do this. We can't close issues directly, but we should be able to give the OP's a satisfactory response and suggest that they close the issue themselves.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Oct 2, 2017

FWIW, the fish-shell has an issue to implement the same idea but in C++ rather than Python. That issue has been open nearly five years. I got tired of waiting for it to be implemented and instead implemented the fish shell argparse command that provides a script friendly interface around the venerable getopt() function. See fish-shell/fish-shell#4190. Even if the C++ implementation of this idea were merged I would still oppose it for the same reason I oppose the Python implementation. It is a fools errand to try and parse text written for humans in the hope of extracting reliable rules for parsing command lines.

That this project has been open more than five years, has generated considerable interest, and still hasn't reached sufficient stability for a version 1.0 release tells me the idea is fatally flawed. That PRs more than a year old are still open is also damning evidence the project is dead.

krader1961 commented Oct 2, 2017

FWIW, the fish-shell has an issue to implement the same idea but in C++ rather than Python. That issue has been open nearly five years. I got tired of waiting for it to be implemented and instead implemented the fish shell argparse command that provides a script friendly interface around the venerable getopt() function. See fish-shell/fish-shell#4190. Even if the C++ implementation of this idea were merged I would still oppose it for the same reason I oppose the Python implementation. It is a fools errand to try and parse text written for humans in the hope of extracting reliable rules for parsing command lines.

That this project has been open more than five years, has generated considerable interest, and still hasn't reached sufficient stability for a version 1.0 release tells me the idea is fatally flawed. That PRs more than a year old are still open is also damning evidence the project is dead.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Oct 2, 2017

Also, note that the last substantive commit was more than two years ago according to this page: https://github.com/docopt/docopt/commits/master

krader1961 commented Oct 2, 2017

Also, note that the last substantive commit was more than two years ago according to this page: https://github.com/docopt/docopt/commits/master

@gusmonod

This comment has been minimized.

Show comment
Hide comment
@gusmonod

gusmonod Oct 2, 2017

That this project has been open more than five years, has generated considerable interest, and still hasn't reached sufficient stability for a version 1.0 release tells me the idea is fatally flawed. That PRs more than a year old are still open is also damning evidence the project is dead.

  1. That a library meant for doing something fairly narrow such as parsing docstrings and command line arguments has a slower development cycle does not mean that it is "dead".
  2. The fact that it may be "stable" and that this stability is more important to the owner than its innovative new features is really just an opinion.
  3. If people want to work on it, and others are happy with seeing it go slow, I see no reason of wanting to "kill" something that others clearly want to work on.

gusmonod commented Oct 2, 2017

That this project has been open more than five years, has generated considerable interest, and still hasn't reached sufficient stability for a version 1.0 release tells me the idea is fatally flawed. That PRs more than a year old are still open is also damning evidence the project is dead.

  1. That a library meant for doing something fairly narrow such as parsing docstrings and command line arguments has a slower development cycle does not mean that it is "dead".
  2. The fact that it may be "stable" and that this stability is more important to the owner than its innovative new features is really just an opinion.
  3. If people want to work on it, and others are happy with seeing it go slow, I see no reason of wanting to "kill" something that others clearly want to work on.
@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Oct 10, 2017

FFS, @gusmonod. The whole point of my comment is that "a library meant for doing something fairly narrow" should not take 5+ years. This is something that should have reached a v1.0 status within a year of the original proposal. That is not to say a v1.0 implementation would be perfect or feature complete. But this project should have reached sufficient stability and implemented all the major goals long ago to be labeled a stable v1.0 release. My comments have nothing to do with the stability of the project. Quite the contrary. A project like this one needs to be stable. But if it had reached a stable state, meaning backward incompatible changes were unlikely before another major release was needed, a v1.0 release have already been made.

It appears the main stumbling block to reaching a v1.0 release status is that the DSL is under specified. That is, as @keleshev said, there needs to be a "Formal grammar". It's not clear that will ever happen but if it did I'd be happy to endorse this project.

I loved that you referred to the fish-shell C++ implementation, @gusmonod. Apparently in a non ironic manner. Feel free to help the fish-shell team implement a C++ implementation of this idea. I'll probably be dead before that implementation is usable. Which is why I implemented the fish argparse command.

krader1961 commented Oct 10, 2017

FFS, @gusmonod. The whole point of my comment is that "a library meant for doing something fairly narrow" should not take 5+ years. This is something that should have reached a v1.0 status within a year of the original proposal. That is not to say a v1.0 implementation would be perfect or feature complete. But this project should have reached sufficient stability and implemented all the major goals long ago to be labeled a stable v1.0 release. My comments have nothing to do with the stability of the project. Quite the contrary. A project like this one needs to be stable. But if it had reached a stable state, meaning backward incompatible changes were unlikely before another major release was needed, a v1.0 release have already been made.

It appears the main stumbling block to reaching a v1.0 release status is that the DSL is under specified. That is, as @keleshev said, there needs to be a "Formal grammar". It's not clear that will ever happen but if it did I'd be happy to endorse this project.

I loved that you referred to the fish-shell C++ implementation, @gusmonod. Apparently in a non ironic manner. Feel free to help the fish-shell team implement a C++ implementation of this idea. I'll probably be dead before that implementation is usable. Which is why I implemented the fish argparse command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment