5 ms·

Show HN: My plugin system/package manager for Git

35 points by joshburnsxyz 5y ago

yjftsjthsd-h 5y ago
What's the source/repo for plugins? That is how does it go from "install foo" to an actual exact thing to install?
- joshburnsxyz 5y ago
  So at the moment I maintain a registry in the form of a JSON file on github (joshburnsxyz/git-plugins-repo) the CLI command parses the raw JSON from that file and then the plugins have a Makefile with the build/install instructions there is also a dummy (joshburnsxyz/git-plugin-dummy) that exists to demonstrate what a plugin looks like and as a template.
  - yjftsjthsd-h 5y ago
    That's not going to scale well; can you get it to just take arbitrary git(hub|lab)/whatever URLs like https://github.com/tmux-plugins/tpm https://github.com/tmux-plugins/tpm , or does it require buy in from the plugins?
    - joshburnsxyz 5y ago
      At the moment i've chosen to go with the hard coded JSON approach purely to get things off the ground, and keep control over what the program is actually doing, accepting generic URLs will require security which is out of scope at the moment.
broodbucket 5y ago
In the current model every plugin you'd have in your repo would have to be aware of your plugin manager, right? I suspect you'd need adoption before authors would want to maintain a Pluginfile.json, and before there's a decent selection in your repo there's not a selling point to gain adoption. A tool that can help me find things like git-series[0] would be cool, but I think you'd need to work downstream rather than having every git plugin know about your package manager. If you're gonna make repos to wrap upstream projects into your package format (which is what Linux distros do), then that could work. [0]: https://github.com/git-series/git-series https://github.com/git-series/git-series
- joshburnsxyz 5y ago
  Correct, as this is the software equivalent of a rough first draft, This is the kind of feedback im looking for. The choice to enforce a format for plugins was done purely to streamline the fetching of metadata (names, authors, links, etc.). If you have any more ideas on what I can do to improve the project, and If you wanted to contribute some of your own ideas, please by all means, open an issue on github.
erjtajrtwjwr 5y ago
Oh yay, another package manager with absolutely no security. Let's pull and execute code from the internet with no way to validate where packages came from or if they've been tampered with.
- joshburnsxyz 5y ago
  At the moment, the only packages being distributed are hand-coded into the repository feed. If/when it comes to blindly distributing users code, security measures would be implemented.
  - erjtajrtwjwr 5y ago
    You're blindly relying on transport security currently, and that's unacceptable even when distributing your own code. Integrity verification of distributed packages (ideally cryptographically) is a core and required feature of a package manager. At an absolute bare minimum you need a Lockfile style mechanism to allow users to ensure two installs are the same.
    - joshburnsxyz 5y ago
      I 100% agree with you, but as i've stated a couple times here now. Once i've got the base of the system solid and working I will then implement proper security measures on-top of that. If you want to jump on-board and help out that'd be great! If you've already got an idea of how all this works then i'd be more than happy to use your expertise to make this project better. After all I am only one person so any help is welcome.
      - smaudet 5y ago
        "Once i've got the base of the system solid and working I will then implement proper security measures on-top of that." I understand your sentiment, but it's wrong. You need to take into account your userbase, potential or otherwise. There are those which will be overzealous and not concerned about security and will use your stuff anyways, then there are those people who find themselves compelled (against their will) to use it, secure or otherwise. Because this software strongly facilitates the later group, releasing it in this fashion represents a security risk and is unethical, wrong, even. Just because you can manufacture a bomb does not mean you should, not should you be distributing bomb making kits. Also, perhaps your time would be better spent building this functionality into existing package managers, rather than this one? There are certainly enough package managers out there, I'm not convinced this is even a good idea.
vgel 5y ago
Does this handle updating plugins? Because just the 'plugin search / plugin add' isn't that interesting to me; I don't use package managers for discovery and since git plugins are so simple I don't see a large benefit over downloading a binary to ~/bin. But, I never remember to keep those manually downloaded binaries up to date, so if this handles that I'd be more interested.
- joshburnsxyz 5y ago
  I do plan on implementing Updating/versioning of the plugins. As mentioned previous - This is still a massive WIP and I am still working on fleshing the basics out.
1023bytes 5y ago
404 Page not found
harry_m 5y ago
I've written another plugin management tool for git. It's called a plugin, but it's actually a manager for git aliases. https://github.com/harunorimurata/git-plugin https://github.com/harunorimurata/git-plugin

35 points by joshburnsxyz 5y ago

yjftsjthsd-h 5y ago

What's the source/repo for plugins? That is how does it go from "install foo" to an actual exact thing to install?

joshburnsxyz 5y ago
So at the moment I maintain a registry in the form of a JSON file on github (joshburnsxyz/git-plugins-repo) the CLI command parses the raw JSON from that file and then the plugins have a Makefile with the build/install instructions there is also a dummy (joshburnsxyz/git-plugin-dummy) that exists to demonstrate what a plugin looks like and as a template.
- yjftsjthsd-h 5y ago
  That's not going to scale well; can you get it to just take arbitrary git(hub|lab)/whatever URLs like https://github.com/tmux-plugins/tpm https://github.com/tmux-plugins/tpm , or does it require buy in from the plugins?
  - joshburnsxyz 5y ago
    At the moment i've chosen to go with the hard coded JSON approach purely to get things off the ground, and keep control over what the program is actually doing, accepting generic URLs will require security which is out of scope at the moment.

broodbucket 5y ago

In the current model every plugin you'd have in your repo would have to be aware of your plugin manager, right? I suspect you'd need adoption before authors would want to maintain a Pluginfile.json, and before there's a decent selection in your repo there's not a selling point to gain adoption. A tool that can help me find things like git-series[0] would be cool, but I think you'd need to work downstream rather than having every git plugin know about your package manager. If you're gonna make repos to wrap upstream projects into your package format (which is what Linux distros do), then that could work. [0]: https://github.com/git-series/git-series https://github.com/git-series/git-series

joshburnsxyz 5y ago
Correct, as this is the software equivalent of a rough first draft, This is the kind of feedback im looking for. The choice to enforce a format for plugins was done purely to streamline the fetching of metadata (names, authors, links, etc.). If you have any more ideas on what I can do to improve the project, and If you wanted to contribute some of your own ideas, please by all means, open an issue on github.

erjtajrtwjwr 5y ago

Oh yay, another package manager with absolutely no security. Let's pull and execute code from the internet with no way to validate where packages came from or if they've been tampered with.

joshburnsxyz 5y ago
At the moment, the only packages being distributed are hand-coded into the repository feed. If/when it comes to blindly distributing users code, security measures would be implemented.
- erjtajrtwjwr 5y ago
  You're blindly relying on transport security currently, and that's unacceptable even when distributing your own code. Integrity verification of distributed packages (ideally cryptographically) is a core and required feature of a package manager. At an absolute bare minimum you need a Lockfile style mechanism to allow users to ensure two installs are the same.
  - joshburnsxyz 5y ago
    I 100% agree with you, but as i've stated a couple times here now. Once i've got the base of the system solid and working I will then implement proper security measures on-top of that. If you want to jump on-board and help out that'd be great! If you've already got an idea of how all this works then i'd be more than happy to use your expertise to make this project better. After all I am only one person so any help is welcome.
    - smaudet 5y ago
      "Once i've got the base of the system solid and working I will then implement proper security measures on-top of that." I understand your sentiment, but it's wrong. You need to take into account your userbase, potential or otherwise. There are those which will be overzealous and not concerned about security and will use your stuff anyways, then there are those people who find themselves compelled (against their will) to use it, secure or otherwise. Because this software strongly facilitates the later group, releasing it in this fashion represents a security risk and is unethical, wrong, even. Just because you can manufacture a bomb does not mean you should, not should you be distributing bomb making kits. Also, perhaps your time would be better spent building this functionality into existing package managers, rather than this one? There are certainly enough package managers out there, I'm not convinced this is even a good idea.

vgel 5y ago

Does this handle updating plugins? Because just the 'plugin search / plugin add' isn't that interesting to me; I don't use package managers for discovery and since git plugins are so simple I don't see a large benefit over downloading a binary to ~/bin. But, I never remember to keep those manually downloaded binaries up to date, so if this handles that I'd be more interested.

joshburnsxyz 5y ago
I do plan on implementing Updating/versioning of the plugins. As mentioned previous - This is still a massive WIP and I am still working on fleshing the basics out.

1023bytes 5y ago

404 Page not found

harry_m 5y ago

I've written another plugin management tool for git. It's called a plugin, but it's actually a manager for git aliases. https://github.com/harunorimurata/git-plugin https://github.com/harunorimurata/git-plugin