forked from tildetown/town
notes on new functionality
parent
e668db7e15
commit
b1f7e9842d
|
@ -14,6 +14,35 @@ import (
|
|||
"gopkg.in/yaml.v3"
|
||||
)
|
||||
|
||||
/* TODO
|
||||
|
||||
I've finished writing the "contrib" half of `town contrib`. but what about the other half? this is two pieces:
|
||||
|
||||
1. as an admin, reviewing what's been submitted and:
|
||||
- discarding
|
||||
- clarifying
|
||||
- accepting
|
||||
2. as a user, running `town` in order to discover and run contrib'ed commands.
|
||||
|
||||
for 2, I think it's fine for now to just let the usage for town get long. as far as how to manage this, i think moving to a folder of yaml files that have an execPath and then dynamically building the command list up from the yaml files works. that way, the contrib yaml can just be copied over (renaming to command name and stripping comments) to the accepted path (/town/commands/contrib or whatever).
|
||||
|
||||
for 1, it can just be manually copying the files but that could easily lead to brainrot and errors, so i want automation there.
|
||||
|
||||
how about:
|
||||
|
||||
town contrib --review?
|
||||
|
||||
it would:
|
||||
|
||||
- list all the commands that have been contribed so dupes can be looked at
|
||||
- iterate through each with:
|
||||
- edit
|
||||
- approve
|
||||
- reject
|
||||
- pass
|
||||
- contact (email)
|
||||
*/
|
||||
|
||||
const binroot = "/town/commands"
|
||||
|
||||
var rootCmd = &cobra.Command{
|
||||
|
|
Loading…
Reference in New Issue