Why Ruby?

[djcas9]

Can't you do this in plain VIML? Maybe with https://github.com/tpope/vim-dispatch?

[junegunn]

Maybe or maybe not. I haven't really thought about it.
But I currently have no problem with Ruby, so I can't imagine myself rewriting it in some other way any time soon.

[ghost]

Well, I don't have +ruby feature in my vim, but all seems to work properly.

[junegunn]

@opennota Unfortunately without Ruby, you don't get parallel installation/update which I think is the biggest merit of vim-plug. vim-plug implements parallel installer in Ruby, and the sequential one in Vimscript.

[ghost]

@junegunn
I'm happy with lazy loading, I don't care much about installation/update speed.

[junegunn]

@opennota I see. I noticed that you don't use many plugins, so I guess you don't really need speed. I use around 30~40 plugins, I was always bored when I was updating plugins with Vundle :)

[ghost]

@junegunn

I noticed that you don't use many plugins

That, and the fact that you don't really need to update when everything works.

[janko]

Well, I think we can all agree that writing this in pure VimScript would probably be a real PITA, so people will just have to have +ruby or Neovim :)

[bruno-]

Hi,
I think the user that opened this thread hinted at something I presumed when I first discovered vim-plug: he/she probably thinks +ruby is *required* in order to use this plugin! (while in fact +ruby is optional)

The false assumption here is probably justified because I don't know of any other plugin out there that has optional lang requirement. It's either it requires a language or it's pure viml.
Any requiring a language might turn off some people that don't want additional external dependencies.

Anyway, might I suggest updating the readme so it's more clear that +ruby is not required for the plugin itself, but for a parallel install feature only.

Thanks

[junegunn]

@janko-m Yeah, and it's not at all hard to get a Ruby-enabled Vim. We get it for free on OSX :)

@bruno- Thanks, that's a great point. I believe the situation is slightly better now, as the part of the page now reads requires +ruby or Neovim, but anyway, I'll think about how I should mention it.

[starcraftman]

Hi @junegunn . Great plugin, thanks for making it. I only recently started using in the new year. I wasn't too happy about the ruby dependence, so I've been making a parallel python update function.

I've now got something working and moved it into an official fork (https://github.com/starcraftman/vim-plug) for tracking purposes. Currently should work on *NIX with just +python, though I've only officially tested on Linux. Would you be interested in eventually pulling this? No PR yet as I need more testing, especially on Mac.

Edit: Kinda putting this here as related, alternative to ruby. Though I can make a new issue of course.

[junegunn]

@starcraftman Hi, thanks for taking the initiative. I know that +python is generally more popular than +ruby, so I think it makes sense to have that version of installer. There are of courses some concerns.

1. It is going to be painful to maintain all 3 versions of installer at the same time, well actually 4 counting nvim support as well. But, I don't see myself introducing a new feature to the installer any time soon, so it's going to be doable, given that you'll help me maintain the code.
2. I hope that the added lines doesn't affect the load time of plug.vim by much.
3. nvim and Ruby versions should take precedence over python version as they have been better tested by the actual users.
4. I have no prior experience with writing Vim plugin using +python. Does it require a specific version of Python? How about +python3? It would be nice if it works with a broad spectrum of versions of Python.
5. We should definitely test python on Travis CI as well. Currently vim-plug is being tested against two versions of Ruby. As far as I know, Travis CI does not support multiple languages, but we could add another version of Ruby and build Vim with python instead of Ruby is that case. Just an idea.

When you're ready please send me a PR, we'll continue the discussion there. Thanks!

[vheon]

@starcraftman I work only on mac at the moment so I'll be glad to test it ;)

[starcraftman]

@junegunn Some responses to concerns you raised.

It is going to be painful to maintain all 3 versions of installer at the same time, well actually 4 counting nvim support as well. But, I don't see myself introducing a new feature to the installer any time soon, so it's going to be doable, given that you'll help me maintain the code.

I agree, adds more complexity. I might recommend an object oriented VimL refactor (after the python PR?) that would reduce our number of if blocks. If done correctly, could make a standard interface for the n number methods we install with. See at the end of my . Just a simple example if you haven't seen the style.

I don't mind maintaining all the python, one of my favorite languages.

I hope that the added lines doesn't affect the load time of plug.vim by much.

I haven't noticed any, I'm pretty sure plugins cause most of the delay. We can check when PR made, I'm doubtful or I'd have felt it.

nvim and Ruby versions should take precedence over python version as they have been better tested by the actual users.

No problem. I shall try and pitch in when I can, know VimL quite well and should read up on nvim jobs. Ruby not as much.

I have no prior experience with writing Vim plugin using +python. Does it require a specific version of Python? How about +python3? It would be nice if it works with a broad spectrum of versions of Python.

+python means python2 only to be clear and +python3 means python 3 only block. The versions required I believe just rely on what libraries used I believe. In my code, I've used stuff that was added around 2.6 so any 2 version after that should work. I don't think there's as many +python3 vim users so I wouldn't put that at top of my list, but support shouldn't be hard.

We should definitely test python on Travis CI as well. Currently vim-plug is being test against two versions of Ruby. As far as I know, Travis CI does not support multiple languages, but we could add another version of Ruby and build Vim with python instead of Ruby is that case. Just a idea.

I will look into this. I don't have experience with Travis, so I'll read up. I'm used to just running my tests locally.

I'll keep this stuff in mind while working on my fork.

[vheon]

I hope that the added lines doesn't affect the load time of plug.vim by much.

These changes can't affect the load time by much. At startup vim loads the vimrc which then call the plug#begin(...) function which cause the plug.vim file to be sourced and then the plug#begin(...) function to be executed. When a file gets sourced (if we consider only the functions) the interpreted note just the name of the function and where it is; it doesn't execute or evaluate anything inside the functions. So since @starcraftman added just 2 functions that will add for a couple of microseconds, so I think is bearable 😏

[junegunn]

@starcraftman @vheon Agreed. I don't think the added overhead will be greater than a millisecond. I just wanted to share every idea and concern that popped inside my head.

The reason I mentioned python version compatibility is that for +ruby, the version can vary greatly. It can be 1.8 or it can be 2.2. So I had to make sure that I was not using any newer syntax introduced after 1.8. So I presumed that you might have to take similar care when writing it in python.

Regarding the refactoring, in this case, the number of if blocks is not a problem but the number of implementations is. So I don't think changing the style would help much.

I'll look forward to your PR, thanks!

[junegunn]

@starcraftman @vheon
Well, now we may have to change the title of this issue to "Why Ruby? Why Python? Why Neovim?" :)

[starcraftman]

@junegunn I await the inevitable, "Why not Perl?" :P