Show HN: My plugin system/package manager for Git | Hacker News Reader

Show HN: My plugin system/package manager for Git

github.com

35 pointsjoshburnsxyz15 comments

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

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.

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.

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.

404 Page not found

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

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.

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.

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.

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.

"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.

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

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.

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 , or does it require buy in from the plugins?

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.

Reply on news.ycombinator.com