Still maintained?

[jepotter1-archive]

Last commit was January 2018. Is this project still maintained?

[wallyqs]

+1 still fan of this approach.

[c4milo]

sadly, I don't think this project is maintained. It will be kind with people to just post a note at the top of the README to state so.

[c4milo]

Just like it was done for the Rust version: docopt/docopt.rs@642e661

[shakefu]

@Aksamyt @arthurschreiber @bicycle1885 @BurntSushi @edwindj @jaredgrubb @johari @kbatten @kblomqvist @keleshev @kipanshi @mboersma @oprypin @ryanartecona @shabbyrobe @voieducode

If the intent is to no longer have the docopt organization maintain this package, can we hand it off to a community maintainer so it continues to be relevant? It's a super useful package for rapidly prototyping Golang CLI tools, and it'd be a shame to throw it away.

If the organization doesn't have the time, I'd be willing to step in and lead the call for maintainers to find someone.

[voieducode]

I think only @keleshev has admin control on the organisation.

[oprypin]

Can you point out some particular things that would need work, not just "had no commits"?

[oprypin]

I may consider reviewing pull requests although I was never involved in this exact repository.
Will also need to check what the story with releases is

[shakefu]

Can you point out some particular things that would need work, not just "had no commits"?

I see several PRs that are still passing which include some edge fixes. But also updating the CI for latest Go 1.16, ensuring the package continues to work into the future, etc. Nothing wrong with a very stable codebase, mind, would be good to see that the community can still contribute back if someone's doing the PR housework.

[shakefu]

@oprypin Any word if this project is going to be left for dead or maintained?

[hoshsadiq]

@keleshev could someone get access to the repo so PRs can be reviewed or something? I'd be happy to step up. I'd like to use docopt but there's a few things that need to be addressed.

[jepotter1-archive]

@hoshsadiq @keleshev I would be glad to help maintain this as well 😄

[oprypin]

@hoshsadiq I have access. But I will not immediately add the first person who asks. If you want to step up, please do review the PRs and tag me.

I still do not see any concrete proposals. Myself, I have no interest in the involved technologies here, but I'll do my best to unblock this situation.
Perhaps the way that this will have to work is by community votes on PRs.

[wallyqs]

It is going to be a bit of an effort to get this project back on track at least initially considering all the changes in Go tooling since them. From a quick overview the project did a GitHub redirection to workaround the issue from old Go versions that did not allow dots in the name (I tried to fix that here #75), and Go modules does not work very well with http redirections from GitHub so there would be a few issues and since this is pre modules likely also need a version bump to v1 before doing that.

If someone wants to tackle things I think this PR would be the place to start: #75
next step would be to enable it with some modules support as in #80, but have to fix the import paths first.

[shakefu]

@oprypin I went ahead and reviewed all the open PRs. #75 probably is the biggest then #80 after retargeting for a more recent Go release. The other approvals are small bugfixes/QoL that shouldn't have significant impact.

@hoshsadiq @JWinnie Do y'all wanna add your reviews as well so maybe @oprypin can get some approval consensus to move forward and unstick this project? 🚀

[jonlundy]

Is there a decent fork that is maintained? It seems the org owner has no desire to add new maintainers?

[shakefu]

Is there a decent fork that is maintained? It seems the org owner has no desire to add new maintainers?

Dunno, but I'm about to start one...

[dexterp]

@Aksamyt @arthurschreiber @bicycle1885 @BurntSushi @edwindj @jaredgrubb @johari @kbatten @kblomqvist @keleshev @kipanshi @mboersma @oprypin @ryanartecona @shabbyrobe @voieducode

Please excuse the blanket post but no one else seems to be picking up the phone. I understand how little time open source developers have but please someone read.

Docopt.go is the 2nd most popular docopts project by stars but no one is available to unblock development which has been blocked for 6 years!

If I may propose.

1. Place a permanent unmaintained notice in the README.md file so that either a fork or some other module can succeed and provide the functionality needed.
   OR
2. Find a minimum set of responsible set of developers that can act as a facilitator for good coding practices. They do not have to be the best developers, but responsible members who understand maintainable coding practices or is at least willing to learn. I suggest I minimum of three that can approve pull requests, and should start off with a probationary period. With that responsibility should come a mindset of guidance towards code quality. For Go and this project the quality guidance document should maybe look something like this.

Proposed guidance document. None of these should be a surprise to any seasoned developer, but I may have missed some crucial ones. I recommend the document be short so that people are not turned off.

1. Code readability
   1. Name functions/methods/struct/interface with a narrow term the code within the function should match that narrow term.
      By keeping your code the same narrow term used in a function name as an example, creates a boundary for the Single Responsibility of that function.
   2. Keep functions short, reducing complexity.
      Code can be benchmarked using a cyclomatic complexity tool which counts the number of pathways a particular function has through its conditionals, loops, selects etc. Gocyclo is an example tool which generates a complexity score per function and creates an average. A complexity count of 10 is the most common but this can be agreed upon, 15 is not a bad choice either.
2. Non breaking changes unless a major release is planned.
   Ensure publicly accessible functions/interfaces keep the same number arguments and types. Any change in this area will lead to a non backwards compatible change
3. Documentation should accompany commits of public functions/structs/interfaces.
4. Unit tests with a minimum code coverage score. I would suggest 80% but this also could be discussed.
5. Suitable entry in the changelog for new functionality, bug fixes.
   Only log change entries that impact downstream module users should be placed and not minoro changes or housekeeping changes.
6. Cooling off period for new features to allow a chance for other features to aggregate. So say a week?

The guidance document could include links to videos that talk about any coding practices that the maintainers wish to include.

What I've suggest really just follows S.O.L.I.D. So any perspective maintainer should know or be willing to learn.

I look forward to your decision.

Warm Regards
Dex

[BurntSushi]

@dexterp Please don't blanket ping people like that. Or at least for me, don't ping me like this for projects that I'm not a part of.

I don't see much point in a notice. The project, and Docopt more generally, are clearly unmaintained at this point. If you or someone else want to continue it, then fork it and change the name.

[jonlundy]

@BurntSushi i believe you were included as one of the 16 members of the Docopt org in an attempt to get a reaction from whichever is an owner to the org. From others in the thread the only owner seems to be @keleshev, who is active on github and in this org as of a few days ago. Why he ignores any requests from this project is unknown.

[dexterp]

@BurntSushi Acknowledge.

[qexk]

@dexterp I agree with both BurntSushi and you.

Docopt is now largely unmaintained and I feel like this kind of project doesn’t attract new people anymore.
Maybe because the other tools have more features, they were used in more corporate environments, or devs think that other devs prefer to read an online manual than a --help output.

Also, some of the projects are mature and “just work”, so they appear to be unmaintained.

---

I believe that a new org with new rules and a new name should be the way to go if we want to preserve Docopt’s ideas.
Here are some ideas for the new projects:

• They must have some sort of code generation as the primary API, insted of parsing the same string every time the program is invoked.
  This adds a mandatory build step if you want to use this feature, but more and more languages have some kind of compile-time code generation (go generate for Go, providers for F#, PPX for OCaml, JS projects using TS must have a build step and Prisma/GraphQL are popular projects that generate code,…).
  Of course this codegen must not be the only way to use the lib, the “old” docopt-style of doing things should still be there!
• This codegen should output types and documentation from the docstring.
• They should provide a getopt_long-style API, it should be easy to use the preexisting codegen code for this. Make it so that people coming from more popular projects feel at home first.

For docopt.go, if you can be better than cobra/viper at handling complex CLIs, that’s already a huge win.

[dexterp]

@Aksamyt @shakefu @oprypin

I know how busy open source developers are so I appreciate the time.

docopt has a good reputation amongst those that have used it, granted it is smaller community than corba. The reason I put forward the two options was to redirect the community to what the new state would be for bug fixes minor updates. Building a new community is hard as you probably know, New volunteers to maintain the current code or potentially transfer the code to another Github Organisation could free up your time. But both these options would need the current communities help in redirection. Simply creating a fork with no redirection would likely kill off the project completely.

I foresee most of the changes will be bug fixes or minor changes which really just needs a few caretakers to look after.

Personally I still use and like the fact docopt needs significantly less lines of code then other libraries. The cognitive burden to understand CLI is far lower when reading docopt code.

I wanted to add sub commands and I saw a bug but hesitated putting in a PR because I saw the state the project is in.

I would like to nominate myself to become a caretaker/maintainer, I hesitate in just forking without redirection, for the reasons said.

I see the redirection or adding caretakers would take minimal effort on your part(s) if you are are the right audience with access. If the right audience is someone else, can you point me in the right direction. I will reach out to that person(s).

[BurntSushi]

I'll re-iterate that I think we should just let the project die.

If one of the existing maintainers wants to step in and breath new life into it, then that's great, they should do that.

But I do not think we should just be adding new maintainers because someone asked to be added. There are risks involved with that. I would really encourage you to just fork and move on.

[jonlundy]

Vladimir Keleshev: I’m making a new reference implementation, first in OCaml, then in TypeScript. Whoever ships a go port of that, will replace the current repo.

https://twitter.com/keleshev/status/1678040088293306369

[hugo-syn]

Any good alternative or maintained fork of this project ?

[shakefu]

Any good alternative or maintained fork of this project ?

I've switched to using Kong. It's based on declarative structs and needs minimal supporting code.