4 ms·
I don't see why he felt the need to halfway add in package management, but not go all the way. You still have to download the package and update it manually fr
by jmcdiesel 10y ago
I don't see why he felt the need to halfway add in package management, but not go all the way. You still have to download the package and update it manually from what i can tell... where the others you simply add a github path (or other repository path) and updates come eaily, install comes easily.
Consider the case of people like me who work on remote servers, who spin up new vagrant boxes and work on them remote... with the package manager as he described it, i'd have to download all the plugins and manually place them, etc... as i currently stand, i install vundle really quickly , then it just reads my .vundlerc.bundles and installs all the plugins i want, presto. Half solutions are worse than no solutions... because now people will compare the two, and default (likely) to the default solution and make package management harder on themselves than it needs to be...
- hellcow 10y agoI don't understand your concern. It seems to me to be roughly the same amount of work whether you A) install vundle and maintain a list of plugins for it to fetch or B) write a bash script that fetches each plugin. I actually prefer Vim 8's approach.
- jmcdiesel 10y agoBecause i can install vundle with a single line in my setup script (already have a "provisioning" kinda script for each time i fire off a machine). I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. Vundle then installs it, and handles it. Could it be scripted, sure... but its much more readable in the vundle form (or other managers for vim), and its also in a more logical place... and its portable, even to a windows machine... its kinda a separation of concerns kinda thing...
- hellcow 10y ago> I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. You either add a single line to your vundle.rc file, or you add a single line to your bash script.
- jmcdiesel 10y agoStill doesn't address separation of concerns... if you prefer a single monolithic script to do everything, thats cool, im not trying to change your mind, but for my tastes, i want my provisioning script to be as simple as possible, concerning only what it needs to, and let the apps configure themselves in a way that is obvious to anyone who uses my scripts (a few of my fellow devs use my stuff to bootstrap their setup)
- jmcdiesel 10y agoAlso, disabling plugins is much easier... just comment the line... instead of delete the folder. That way, if im working through an issue that a plugin is causing, i can easily just toggle the plugin. Vim just loads whatever is in the folders, so i'd have to delete the folder, then readd it when i want it back... its less of a use case, but since i write vim plugins from time to time, its nice to be able to easily turn on/off my own plugins that may have bugs in them when i need to actually work...
- tetraodonpuffer 10y agoI don't know you, but personally for something as sensitive as an editor that I use to work on code, I do NOT want automatic updates or the editor to connect to random websites to pull code I have not inspected. I would rather have a directory with a few plugins I vet, and scp that around the place if needed. I am actually getting a bit get-off-my-lawn with some extensions in emacs that are all "manual installing is not recommended just use melpa"
- mikewhy 10y agoSome do, some don't, but the person you're replying to only mentioned manually updating, which is how many (all?) Vim package managers with. Then if you do want auto-updates you just call "PlugUpdate" in your .vimrc
- wolfgang42 10y agoThe analogy I imagine is the node_modules folder--you build the minimal infrastructure to make a package manager possible, then let someone else come along and figure out the best way to actually make it (i.e. npm, but also ied and yarn).