How about maintaining a list for all plugins?

[adoyle-h]

just maintain a list in the README, wiki or anywhere else. It will be convenient to browse a tpm plugin.

[bruno-]

Interesting idea, I like it. I think "tmux plugins" thing it not big enough (yet), but we can start thinking about it.

Is there something similar out there we can look up to? (not counting the advanced systems like ruby gems, we wanna keep it simple).

An idea for the future: maybe we wanna use plugin list so specifying plugins in tmux.conf is even easier?

Anyway, ideas and volunteers for maintaining this are welcome!

[adoyle-h]

@bruno-

Is there something similar out there we can look up to? (not counting the advanced systems like ruby gems, we wanna keep it simple).

I found the bpkg. It is a bash package manager, so is similar to tpm. But we can still draw on the pros of it.

An idea for the future: maybe we wanna use plugin list so specifying plugins in tmux.conf is even easier?

Yes. The list is a centralized place for collection. Maybe we can write a script for browsing a plugin from the list.

So how to keep it simple? Here is my solution:

Maintain the list: Create a plugin-list file, which stores all metadatas of packages, in the repo (or new one).
The metadata structure likes that:

{
  "name": "username/package-name",             // required. The name of package. The "username/" is for preventing naming conflicts. username could be a organization name such as "tmux-plugins".
  "author": "username",                        // required
  "email": "username@gmail.com",               // optional. For contact
  "version": "0.0.1",                          // required. Suggest to follow SemVer
  "description": "Terminal utility functions", // required. A human readable description of what the package offers for functionality.
  "tags": ['bash', 'tool'],                    // optional.
  "install": "make install",                   // required. A shell script used to invoke in the install script.
  "source": "https://github.com/username/package-name", // where to fetch the source code
}

Maybe using YAML format is better. Because the comma in json easily leads to the git merge conflicts.

Submit a plugin: Anyone can submit his/her package via editing the plugin-list and making a pull request to the repo.

Browse a plugin: The script for browsing can download the raw plugin-list file and parse it for specific information.

All above are my opinions just for your reference.

[bruno-]

Hi @adoyle-h,
I like your suggestions, thanks. All the fields make sense.

Do you know if it's hard to work with json / yaml format from shell or bash? I'd hate to have an external dependency just for this.

The easiest thing to do would be to have tab-separated fields, one plugin per line. The downside is that it's hard for humans to read, especially if fields don't have "keys". Also this format is less extensible when compared to json above.
Example:

username/package-name         username         username@gmail.com         0.0.1         etc...

[chriszarate]

How about a simple wiki page until this is sorted out? I've created a few tmux plugins that I think others might find useful:

https://github.com/chriszarate/tmux-tasks
https://github.com/chriszarate/tmux-docker
https://github.com/chriszarate/tmux-struggle-bus