town/cmd/contrib

contrib (town contrib)

the point of this command is to request to an admin that a particular executable path be exposed via the town launcher.

mockup

town contrib ~/bin/mycoolexe
? How should the new command be called? [mycoolexe]
? What is a one line description of this program? cool dingus
? What category is this program in?
  artistic
  game
  utility
> social
  misc
? Press e to open your editor and write a longer description of this program...

FYI! you will be the maintainer of this command and only you (or an admin) will be able to make updates to it once it is approved.

v created request for command mycoolexe. if too much time passes without addition, bother vilmibm.

# uses uid to guard updates
town contrib -u mycoolexe ~/bin/newpath/mycoolexe
...updated path for mycoolexe to ~/bin/newpath/mycoolexe
? Want to edit other stuff (description, category, etc) [yN] n

# uses uid to guard updates
town contrib -d mycoolexe
? To confirm deletion of mycoolexe, type its name: mycoolexe

v deleted mycoolexe

# enforces admin access
town contrib --admin ~someone//bin/something
? How should the new command be called? [something]
? What is a one line description of this program? cool dingus
? Who is the maintainer? [vilmibm] someone
? What category is this program in?
  artistic
  game
  utility
> social
  misc
? Press e to open your editor and write a longer description of this program...

in addition to this new interface, i want to change how commands are tracked. the script + yaml file is very cumbersome and confusing and has the bad race condition of the two files not being written at the same time. it means i hate adding commands.

• sqlite3. a little overkill.

• json file. a little underkill.

    what am I doing. should there even be a system like this? what about just letting anyone add anything? i think we're big enough that we shouldn't go moderation less and i can also help guarantee things are runnable and maintainable, this way.
  
    i have a gut feeling that involving SQL here is bad. I like the flat file approach for requesting that something be added to core; those are easy to review and tweak, but after that, what to do? right now the town launcher consumes a directory of flat files to create the command hierarchy. i could keep that code the same. the ultimate issue is having to have the corresponding executable. right now, that might be a bash wrapper that i write; it could be a compiled executable; it could be a script someone else writes; as of now, it doesn't seem like it can be a symlink which i think is good.
  
    several of the wrapper scripts are just calling the executable path and passing args; i think i should just do that from go.
  
    so we'll have: /town/requests/contrib to store requests to add. once added, they will go to /town/commands/contrib as a yaml file with no need for a corresponding executable.
  
    competing with this, i want a `town wild` command that can call any executable in a world writeable dir. because it's funny