Replies: 3 comments 2 replies
-
I think that one of the best extensions would be |
Beta Was this translation helpful? Give feedback.
-
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:
![2023-08-08-112331_1919x726_scrot](https://github.com/zdharma-continuum/zinit/assets/6049288/d26f1cac-a47f-4a8d-9f90-05f2de8655e9)
like this:
![2023-08-08-112155_1919x652_scrot](https://github.com/zdharma-continuum/zinit/assets/6049288/f8bc9370-d0ce-4a21-be08-d38e81c99578)
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
|
Beta Was this translation helpful? Give feedback.
-
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.
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
You can specify tags you want to use for a specific plug-in currently, I think
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).
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
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. |
Beta Was this translation helpful? Give feedback.
-
The idea is to gather only AppImage files, with some nice extension, like e.g.:
my-plugin-v1.7.zplg
ormy-plugin-v1.7.plg
(or maybe some more distinct ones, following the quite distantegg
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 likekeep
would be given). What do you say? The delay of mounting wouldn't matter because of Turbo.Beta Was this translation helpful? Give feedback.
All reactions