Skip to content

Instantly share code, notes, and snippets.

@Supinic

Supinic/commands repo.txt

Last active May 26, 2020 11:52
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save Supinic/6a634b1bb94d3a3441653179cb873164 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save Supinic/6a634b1bb94d3a3441653179cb873164 to your computer and use it in GitHub Desktop.
Download ZIP
Repository for Supibot commands
Raw
commands repo.txt
1. Repo will be new, and separate from anything that concerns the `supibot-sql` repo
- (idea: supibot-sql is just a version control for whatever the main instance does)
2. Implement a method into `sb.Command` to "install" a new command from a description object
3. sb.Command.install will also handle duplicates - will update instead of failing (like now)
4. Repo command definitions will be in `.js` syntax as IIFEs that return a description object
5. Each command definition should be prefaced by an author/ownership comment
6. Think about some sort of authorship/source signature hash, not necessarily as a part of the definitiion but rather as a separate file or a list of hashsums in the root dir
@Supinic
Copy link
Author

Supinic commented May 26, 2020

each command could also have the source it was downloaded from in the table, making it easy to group

the problem I have with this is the data type, or rather uniqueness of the table's column values
let's say commands have sources Alice and Bob, would the Source column be a unique VARCHAR? or an ENUM?
ENUM seems to be out of question since we don't want to force people to update their tables on the go
a unique column would work alright I suppose

@Mm2PL
Copy link

Mm2PL commented May 26, 2020

I would think of the source as the Github repository (username/repo_name) or even path to the command (username/repo_name/commands/command.js).

@Supinic
Copy link
Author

Supinic commented May 26, 2020

  1. sb.Command.install will also handle duplicates - will update instead of failing (like now)

IMO this should be a flag to not accidentally override a command.

the best approach would imo probably to have flags for both

  • installable commands (to separate commands that should not be installed remotely)
  • overwritable commands (which along with the install flag would update themselves as needed)

I would think of the source as the Github repository (username/repo_name) or even path to the command (username/repo_name/commands/command.js).

does this mean there would always have to be two copies of a command? one in the "aggregate" repo and one in each author's repo?
i feel like custom version control repos shouldn't be connected to this repo

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