Registering versions upon install/update in a lock file

[lloeki]

While #253 is concerned with manually specifying a sha/tag/branch/version, my request has more to do with not specifying them, but recording what has been installed, so that the exact same setup can be replicated, without manual version management.

This is in Ruby land, the role of the Gemfile.lock file (its role is also to record the version of each gem dependencies, recursively)

Say the bundle.vim file contains:

Bundle foo
Bundle bar
Bundle baz 0.1.2

Running BundleInstall would perform installation of each repo, and for each one, it would fetch and install the latest or manually specified version, record the version installed in a bundle.lock file.

Running BundleInstall again would read bundle.lock, check currently set versions, and not do anything.

Running BundleUpdate would read the bundle.lock and install only newer versions, recording those in the process.

Running BundleUpdate bar would act like BundleInstall for every plugin except bar, for which it would act like BundleUpdate. If bar requires a newer version of a currently installed dependency that what is currently installed (hence an unsatisfied dependency), it will act like BundleUpdate for that dependency, but if the dependency is satisfied it will act like BundleInstall for that dependency. If bar requires new dependencies it will of course act like BundleInstall for those new dependencies.

The file bundle.lock should be committed by users into source control, so that a fresh setup on a new machine results in the exact same setup as everywhere else.

[twe4ked]

Sounds like a good idea to me. @gmarik do you have any thoughts?

[a-b]

It appears like version management is a huge blocker for https://github.com/carlhuda/janus/issues/512#issuecomment-22451860

[MarcWeber]

We at VAM decided to not have such features because the more versions you have the more combinations - the more ways to test - community is not that huge. Thus we at VAM limited us to "use latest versions and fix bugs fast" following the 20% of effort should yield 80% of value. If something really breaks git has git reflog show .. to revert - an alternative would be putting everything into git submodules to "version lock" all git repositories. VAM has an experimental implementation, but it doesn't work that nicely yet because most plugins look dirty because some plugins get patched (eg a addon-info.json file gets added). I think this should be turned into a TODO item (think about it)

[jdevera]

This sounds like a very complex feature that can be worked around with user scripts. I'm not sure it is in the scope for Vundle. @gmarik ?

[Shougo]

This sounds like a very complex feature that can be worked around with user scripts.

Yes, I think so, too.

[MarcWeber]

We should move discussion to #189 because that actually implements such a feature

[lloeki]

No it does not. #189 is the same as #253. This bug report is about not specifying refs manually but storing the ones that have been used, and using them thereafer, automatically.

Also, I supposed the point of Vundle was not to hack around with user scripts. Git submodules, seriously? Should I just go back to pathogen? because that's how you do it there. And I've done that for years, and it's a pain.

[Shougo]

OK. I get it. It is not #189. But to implement this feature, Vundle must support #189 feature. So, it is complicated feature than #189.

This bug report is about not specifying refs manually but storing the ones that have been used, and using them thereafer, automatically.

This is not bug report. It is new feature request.

[MarcWeber]

@lloeki features can be optional, too. (In fact think about how many options Vim offers you don't use, do you go back to any other editor for that reason?)

[lloeki]

@Shougo fair enough.

@MarcWeber I'm all for things being optional, but the feature has to exist in the first place and this one does not, even with #189 implemented: see the difference between Bundler's Gemfile with git + ref options vs Gemfile.lock containing SHAs.

[MarcWeber]

"Should I just go back to pathogen?" This question didn't make sense - it was just my way of telling you this. I'd like to unify and collaborate. Do you think this make sense: https://bitbucket.org/vimcommunity/vim-pi/issue/95/ ?

All plugin managers could support it (if they want to do so). Vundle will never be my tool, #388 case. Fixing vundle would mean turning it into what vim-addon-manager already is.

[lloeki]

Do you think this make sense

Not in the context of Vundle. The need here is merely to record in a file what version has been installed so that the exact same setup can be trivially restored without having to track SHAs manually.

If the above Install/Update algorithm sounds too complex, then consider the following scenario as typical and immensely useful already:

Say I have a bundles.vim file containing the lines:

set rtp+=~/.vim/bundle/vundle/
call vundle#rc()
Bundle 'gmarik/vundle'
Bundle 'kien/ctrlp.vim'
Bundle 'bling/vim-airline'

Then running vim -u bundles.vim +BundleInstall +qall would produce a brand new bundles.lock file along the existing bundles.vim one, containing the exact version info:

BundleLock 'gmarik/vundle' '08e9894d2a9452537663f09a73ddeb4e647e9c4c'
BundleLock 'kien/ctrlp.vim' 'b5d3fe66a58a13d2ff8b6391f4387608496a030f'
BundleLock 'bling/vim-airline' 'b5d3fe66a58a13d2ff8b6391f4387608496a030f'

Adding that file to my vimfiles favorite version control system and pulling on another computer, then running the same vim -u bundles.vim +BundleInstall +qall would just work, while using BundleUpdate would just ignore and rebuild the lock file.

@jdevera @Shougo does that sound less complex to you?

Points subscribing to Vundle philosophy:

• trivial to use
• backwards compatible from the point of view of the user: BundleInstall and BundleUpdate work the same way as before
• no manual specifying of SHAs
• no surprises
• file is valid vimscript: no parser needed, just source it

[Shougo]

@jdevera @Shougo does that sound less complex to you?

I have already got this feature. But I think it is complex feature to implement in Vundle. Neobundle already has version lock feature. So, I can create the branch for it.

[Shougo]

@lloeki I implemented the feature in "lock" branch in neobundle. You can check it.