Sounds like Bram disagrees with almost my entire premise, so probably Docker stuff'll just get merged into Vim. Responding point-by-point anyway.
On Fri, Aug 22, 2014 at 12:40 AM, Lokesh Mandvekar <[email protected]> wrote: > On Thu, Aug 21, 2014 at 04:43:58PM -0400, Benjamin R. Haskell wrote: >> As with the Docker Zsh completion file that just got included in >> upstream Zsh, I'd prefer that this doesn't make it into Vim "proper". >> Including it in another project just makes changes harder to > > From a distro package perspective, using zsh completion or vim syntax from > contrib causes ownership issues (certainly on fedora and its > downstreams, perhaps other distros too) as the dirs in which these files would > be installed are owned by other packages. See: > https://bugzilla.redhat.com/show_bug.cgi?id=1127570#c3 > Including them in the main repo would solve that. I have no idea how Fish is typically structured, but I'd be surprised if it were different from how Zsh and Vim have a "site packages" directory, which isn't generally owned by the relevant program. E.g. on my current (Arch) system, there's a `/usr/share/vim/vimfiles` directory, which contains the following files owned by packages other than `vim`: ``` compiler/lilypond.vim is owned by lilypond 2.18.2-2 ftdetect/augeas.vim is owned by augeas 1.2.0-1 ftdetect/lilypond.vim is owned by lilypond 2.18.2-2 ftplugin/lilypond.vim is owned by lilypond 2.18.2-2 indent/cmake-indent.vim is owned by cmake 2.8.12.2-2 indent/lilypond.vim is owned by lilypond 2.18.2-2 syntax/HGAnnotate.vim is owned by mercurial 3.0-1 syntax/PKGBUILD.vim is owned by pacman 4.1.2-6 syntax/asciidoc.vim is owned by asciidoc 8.6.9-1 syntax/augeas.vim is owned by augeas 1.2.0-1 syntax/cmake-syntax.vim is owned by cmake 2.8.12.2-2 syntax/lilypond-words is owned by lilypond 2.18.2-2 syntax/lilypond-words.vim is owned by lilypond 2.18.2-2 syntax/lilypond.vim is owned by lilypond 2.18.2-2 syntax/tmux.vim is owned by tmux 1.9_a-1 ``` > If it's only Fedora's/RHEL's problem and if others don't want it included > here, I'm cool with bugging the package maintainers to include this in > their rpms. > >> propagate. Instead of taking just a pull request against the Docker >> repo, a change goes through the idiosyncratic (and slower) Vim runtime >> files change process (which apparently still involves emailing files >> in the year 2014). > > The files that were upstreamed certainly won't be deleted from docker/contrib > as per > https://github.com/docker/docker/issues/7657 . I guess some people > could take it upon themselves to periodically upstream changes from > docker/contrib. That was part of my main thrust with: >> - They contribute to the amount of maintenance work Bram has to do >> - ... >> - They can't be updated as easily as they can if developed independently I'd be happier if there was no effort needed to periodically upstream changes, because whoever packages Docker would handle packaging the related Vim syntax files. >> I think the state of the Vim ecosystem would be much better if: >> >> 1. Vim shipped with (or at least advocated the use of) a reasonable >> plugin/addon/package manager >> - This would at least discourage the poor manageability of "Just >> untar this into ~/.vim" >> >> 2. Vim didn't distribute (m/)any language-/tool-specific addons >> - They contribute to the amount of maintenance work Bram has to do >> - They detract from the amount of work that can be done on core Vim >> - They can't be updated as easily as they can if developed independently >> - They're subject to Vim's licensing (... kind of?). (At a >> minimum, licensing has to be considered. In the separately-developed >> scenario, it's simply not a concern.) >> - They're weirdly tied to a single (point of failure) author. >> >> 3. Projects (like Docker) that have Vim files would set them up in a >> way usable by (a) Vim plugin manager(s). >> - "Via pathogen, the usual way..."¹ seems a bit glib/useless >> >> #'s 1 and 2 are obviously out-of-scope for this Docker-specific >> request. But #3 should be easily achievable, AFAICT: >> >> My preferred plugin manager, Vundle², for example, makes installing >> the Docker syntax files as simple³ as adding one of the following to >> `.vimrc` or equivalent: >> >> ``` >> " if installing from scratch: >> Plugin 'docker/docker', {'rtp': 'contrib/syntax/vim/'} >> >> " if you already have `docker/docker` checked out: >> Plugin 'file:///home/bhaskell/git/docker/contrib/syntax/vim' >> ``` > > Haven't used plugin managers myself, and I'll be sure to try them out, but > I think the aforementioned file/dir ownership issues would be > applicable in this case too. Correct me if I'm wrong. Depends on the level at which you're attacking the problem. From an end-user-on-a-single-user-system perspective, adding one of the lines above installs the file (typically) into one's home directory (`~/.vim/bundles/` by default with Vundle). And, Vundle's really only intended for use by an end user, so I'm not sure how it could play into packaging. -- Best, Ben -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
