Could zinit utilize AppImages for single-file plugins?

[psprint]

The idea is to gather only AppImage files, with some nice extension, like e.g.: my-plugin-v1.7.zplg or my-plugin-v1.7.plg (or maybe some more distinct ones, following the quite distant egg from Python… like e.g.: my-plugin-v1.7.entail, or: my-plugin-v1.7.ent, or: my-plugin-v1.7.embed, or: my-plugin-v1.7.emb, or: my-plugin-v1.7.drive, etc.) and only mount them on time of load, i.e.: call ./my-plugin-v1.7.ent --mount and load from the directory mounted in /tmp/…. After loading, the plugin would be unmouned or not (if an ice like keep would be given). What do you say? The delay of mounting wouldn't matter because of Turbo.

[psprint]

I think that one of the best extensions would be my-plugin.zimg or maybe just ….img. What do you say?

[psprint]

And the building would be very easy – via a new zinit img build sub-command… no other actions would be required. The AppRun file could be automatically pointed to a demo of the plugin, so running ./my-plugin.zimg as exec file would trigger the demo or a help/usage information.

[psprint]

After working on the feature's annex (it'll be a shipped annex, no need to load it explicitly) I think that I've got the perfect extension: my-plugin-v1.0.mg, i.e. a "miligram" :) What do you say, @vladdoster @pschmitt @alichtman ?

[psprint]

Separately: I don't really understand what functionality this feature unlocks. What can you not do with zinit currently that you'd be able to with this feature?

Before AppImages and flatpaks appeared there was a problem for distributions that "we weren't providing any binaries for Linux". Those are LInus words. Today many new applications appear and are shared as binaries on GitHub releases page, before even appearing to distros. The "new software" can be also downloaded from FlatHub. Similarly. for zsh plugins the problem is that we don't provide packages, only GitHub repos. Think of your plugins-dir – how many git repos does it contain? Is it good that so many complex git dirs are there spread over that directory? Wouldn't it be better that the directory would look instead of like this:  like this:  The AppImages are perfect solution because they're simply a portable,mountable filesystem images. I cannot think of anything better for Zsh plugins. You ask what it unlocks? - the plugins become release-based rather than git-HEAD based, - no cluttering of plugins dirs with thousands of files in .git dir, - easy moving, copying of files between machines, - easy backup of a plugin that works just fine and user doubts necessity of update, - the plugin solution for Zsh may grow into a full featured package manager like eggs, gems, node modules – because they'll have a version assigned and could easily include dependencies, - we could easily use a env var like PYTHONPATH that would point to dirs with the milligrams, - it would be easier to equip a software with a Zsh bundle, - imagine that you'll have to distribute Python packages as source… painfully, uh? but this is what we currently do in zsh plugins… we distribute the source files… - java has *.jar's, ruby has *.gem's, python has eggs, o let Zsh/Zinit have milligrams / *.mg's.

…

-- Best regards, Sebastian Gniazdowski

[alichtman]

I removed my earlier comment as I wanted some more time to think about this feature before engaging in discussion, but that ship has sailed :)

It feels like zinit is trying to become a full system package manager, and I don't think that's the right place for it. I use zinit to load a few nice zsh integrations, and use my system's package manager to do the heavy lifting of package management.

Think of your plugins-dir – how many git repos does it contain? Is it good that so many complex git dirs are there spread over that directory?

A few. I don't ever look at it. The "complexity" (of cloning a few git repos) is hidden from the user and they never have to think about it. I have directories of tens to hundreds of git repos that I've worked on over my career. It doesn't bother me. We can use bare git clones if we want to optimize for space. This doesn't strike me as a serious problem. (Although I can't see your images in the mobile app. Unclear if that's a bug or if they weren't attached fully)

zinit supports the XDG spec, and I never think about what the zinit "output" looks like since everything is "hidden" from me

the plugins become release-based rather than git-HEAD based

You can specify tags you want to use for a specific plug-in currently, I think

no cluttering of plugins dirs with thousands of files in .git dir

The plug-ins dirs are hidden somewhere deep in the XDG Cache. I don't ever look at them, and they don't take up that much space (on the order of KB).

easy moving, copying of files between machines

The cool thing about zinit is that you can reinstall your shell setup with the zshrc file. I don't think we should engineer for easy copying of files between machines. This isn't zinit's problem to solve

the plugin solution for Zsh may grow into a full featured package manager like eggs, gems, node modules – because they'll have a version assigned and could easily include dependencies

Maybe I am the wrong person to talk to about this, since the way I use zsh/zinit is far different from what you're suggesting. I wouldn't use these features personally. This doesn't need to be production quality (If it did, I wouldn't have chosen to write it in zsh). I tolerate some intermittent breakages for the convenience of sourcing ~10 plugins from GitHub.