i write a new vim package/plugin manager like debian's apt

[孔晓泉]

hello everyone:
recently i write a new vim package/plugin manager .because it
operate like dbian's apt, so i call it "vimapt".
here is the repository https://bitbucket.org/howlanderson/vimapt
and some article in my blog http://www.howlanderson.net/?cat=33
Notice: vimapt is just in alpha, unstable and may full of bugs
I hope you can try it, whether you think it is good or bad, please
give me some feedback, Thank you very much!

[Marc Weber]

Excerpts from 孔晓泉's message of Sat Mar 09 05:42:23 +0100 2013:

Hy 孔晓泉,

In the future please write to the mailinglist *before* you start *yet
another package* for doing a task. Because there are already many
implementations:

pathogen
vundle
vim-addon-manager
vimana
(and probbably some more)

Then give those projects a try, and consider contributing (if they
philosophy is close enough to your ideas) - if not - document in which
way your solution is different. This will make it easier for other
people to know whether they want to give your solution a try

Your very last sentence sasy:

== Inspiration and ideas from ==
vundle
pathogen
bundler
Scott Bronson

which clearly shows that you've missed vim-addon-manager, which might be
closest to what you've been looking for.

Which in turn makes me think we should no longer wait, we have to setup
the git based wiki system on www.vim.org ASAP, else this will happen
over and over again and split the community.

Its great that people around Vim do solve problems - step up and get it
done. But the Vim eco system sucks so much - that energy is wasted a
lot. And we as community have to fix that.

If you think different don't be shy and tell me.

Marc Weber

[stosss]

I can respect your argument and see the validity to it. So tell us why
your project to coordinate this effort is better than some of the
others that are out there? I don't a have a pro or con to yours or any
of the others that exist or could exist. Also at present I don't use
any of the existing options. I have I think 3 plugins. But as I
continue to learn more ways to use vim to a greater degree to
manipulate text files I might start adding more plugins to my vim
install. So why should I use any of these efforts?

[Charles E Campbell]

Marc Weber wrote:
<snip>

> Your very last sentence sasy: == Inspiration and ideas from == vundle
> pathogen bundler Scott Bronson which clearly shows that you've missed
> vim-addon-manager, which might be closest to what you've been looking
> for. Which in turn makes me think we should no longer wait, we have to
> setup the git based wiki system on www.vim.org ASAP, else this will
> happen over and over again and split the community. Its great that
> people around Vim do solve problems - step up and get it done. But the
> Vim eco system sucks so much - that energy is wasted a lot. And we as
> community have to fix that. If you think different don't be shy and
> tell me. Marc Weber

No call to panic -- there's plenty of partial duplication out there. In
fact, the bundlers themselves are largely duplicative of what vim
natively provides. And, there's vim.sf.net, which has been around for
years. So, git itself is another duplicative source of vim plugins.

The more the merrier.

Regards,
C Campbell

[孔晓泉]

dear Marc Weber:
yes, i agree some point of your ideal. now let's explain some thing:
1. vundle && pathogen
i read their code and i think their function are quite less.
why i want write a another manager? because:
1.1 some plugin need out of band program to help them, such as ctag,
package manager should do something on it
1.2 some plugin need python support or set nocompatible，but unless you
read the doc before, you will fall and you don't know why
1.3 with the plugin's function is more and more complex, some public
vim script library have appeared "L9 : Vim-script library", dependency
will manage
1.4 auto-tools and interaction of other programs, let bash write
package name into your .vimrc is not the good path, at least i don't
think so.
1.5 security, wild plugin on github or something may curse security
problem, you can't guarantee that. user may write a wrong git address
that will horrible
1.6 copyright , although copyright is not your care, but in law, it is required
2. vim-addon-manager
sorry, that's my fault. but there is too many plugin manager called
"vim-addon-manager". what i first found it's the ubuntu's package
called "vim-addon-manager" which is write in ruby. well i don't like
that, not only you will install ruby for this but also i hate ruby
things for my personal reason. and it's looks not a good manager in my
point of view. may be what your means "vim-addon-manager" is this
http://www.vim.org/scripts/script.php?script_id=2905 or
https://github.com/MarcWeber/vim-addon-manager which may write by you
judged by author's name. it's really a good job.　it look's a little
simlar to my job on functions.
3. vimapt
Sentence summary is "apt on vim", this is what i want

If you think different don't be shy and tell me.

2013/3/9 Marc Weber <marco-...@gmx.de>:

> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ben Fritz]

On Saturday, March 9, 2013 4:06:10 AM UTC-6, MarcWeber wrote:
>
> which clearly shows that you've missed vim-addon-manager, which might be
>
> closest to what you've been looking for.
>
>
>
> Which in turn makes me think we should no longer wait, we have to setup
>
> the git based wiki system on www.vim.org ASAP, else this will happen
>
> over and over again and split the community.
>
>
>
> Its great that people around Vim do solve problems - step up and get it
>
> done. But the Vim eco system sucks so much - that energy is wasted a
>
> lot. And we as community have to fix that.
>

All the OP would have needed to do to figure out that his problem had already been solved, is to visit Google or Bing or whatever and type "vim plugin manager" in the search box.

[孔晓泉]

dear Charles E Campbell and stosss:

maybe you can find my answer in to Marc Weber's letter. sorry. i have
something to do this morning. so i don't have much time. if not i will
explain to your question myself.　Happy to discuss with you all. Thank
you for your pingback.

2013/3/10 孔晓泉 <u1ma...@gmail.com>:

[Jon Cairns]

> Its great that people around Vim do solve problems - step up and get it
>
> done. But the Vim eco system sucks so much - that energy is wasted a
>
> lot. And we as community have to fix that.

Is this really a problem? Bottom line is this: coding is fun. People should write more code, and open source it. I would encourage people to solve problems that have been solved before, purely because it's fun to solve problems and that's how you learn. It can be a lot harder to contribute to existing projects, and you may not be ready to take on that challenge.

If the OP had said that he wrote it because all other package managers sucked then I'd have a problem with that, but it sounds like he's doing it for fun and seeing where it's going.

Open source software has a life of its own anyway: people will only adopt it if it has genuine benefit over other options. I've written a few plugins, some of which have been adopted by quite a few people, and some that have literally no adoption. But I use them all every day, and choose to open source them just in case their slight differences to other plugins are just what others need too.

I do think you have a valid point, but I think that the greatest danger here is quenching people in the open source community from doing what we do.

[Marc Weber]

> @C Campbell
> The more the merrier:
The community has resources. And the community has wishes. The better the
resources are spent on what makes the community happy - the better for everyone
(IMHO).
If evrybody keeps solving the same task over and over again -> no progress.
I know its part of life - but still we as community can try to optimize it - or
be careless. I want to take care.

If people want to redo something for joy they may do it. But if they announce
on the mailinglist I think they should also tell people about why they think their
tool should be used by users.

@孔晓泉
I like you participating.

> 1.1 some plugin need out of band program to help them, such as ctag,
> package manager should do something on it

Can you tell me why you think it should be the "package managers task" to
provide ctags?

To prevent "desperation" on user's side 3 lines are enough:

if !executable('ctags')
echoe 'well, you don't have ctags. Read the docs to learn where to get it'
endif

Let's think the way you do: It should be the task of the package manager to do this:
What would be required? A solution for:
windows
linux (there are many different packaging systems around, at least yum, apt-get, nix)

For this reason I agree that it would be nice if "vim" could just install a package.
But in fact I think it would be enough if Vim showed a hint:
"do apt-get install ctags"

Maybe we could even write a viml plugin doing exactly that: propose
installing packages if they don't exist. Then you could use

call vim_install_helper#SuggestInstall("ctags")

and it would be the task of the plugin to figure out which is the best
way to install ctags on the operating system the user is running.

If there is no implementation it would just say:
"ctags required, don't know how to suggest installing it. Please patch
me and contribute".

I don't want vim to run sudo apt-get .. anyway without being asked. So
creating a new install hepler plugin seems to be the right thing to do.

So I think its the task of the plugin to check whether all conditions are met
so that it can be run. But I disagree that its the task of the plugin or the
package manager to decide on which packages I want to in install on my computer.

> 1.2 some plugin need python support or set nocompatible，but unless you
> read the doc before, you will fall and you don't know why

Again, I disagree. I don't want a vim plugin manager to
1) download vim source
2) configure it
3) compile and install it somewhere

which is a better way to handle it?

fun CheckThenRun(fun, args)
if !has('python')
throw "this plugin requires python support"
endif

return call(a:fun, args)
endf

Then you can use

map <F2> :call CheckThenRun('your_impl#Fun',[<f-args>])

or the like - and user will get a nice message telling him what's wrong.

> 1.4 auto-tools and interaction of other programs, let bash write
> package name into your .vimrc is not the good path, at least i don't
> think so.

Of course you have to think twice or trice before doing such.
But why is it necessary ? Which problem is solved by such a bash script?

2.
vim-addon-manager: Yes, its about that github page, it was initiated by me.
Today its maintained by me and ZyX.

3. apt on vim?

apt: its you calling
apt install foo
apt install bar

apt writes to a databse "foo and bar are installed"

How does VAM solve this? Compared to apt Vim tries to be declarative (as much
as declarative as you can be):

You add to your .vimrc:

call make_sure_vam_is_installed_otherwise_checkout_from_git()
vam#Activate(["foo","bar"])


Then you don't have to install apt, all you have to do is copy your .vimrc in
place and make sure you have git.

Next difference. Let's think about this use case:

When coding java you want plugin A,B
when coding viml you want plugin A,C

but you can't use B and C together.

With VAM you can activate B or C as needed, eg by using project
setup viml file sourced by vim-addon-local-vimrc.

For this reason I think that I'm more likely to run into trouble using apt like
system. I don't want to go back to apt, cause I know and I'm used to the same
declarative way nixos manages linux packgaes - I can't go back.

@Ben Fritz:

> All the OP would have needed to do to figure out that his problem had
> already been solved, is to visit Google or Bing or
> whatever and type "vim plugin manager" in the search box.

Sorry, I personally believe in the community being able to do a better job than
google does. Google never forgets - but a guide about how to use vim should
forget some ideas or mark them as outdated.

@Jon Cairns
> Is it a problem ? coding is fun?
If 孔晓泉 was coding it for fun, you're right. At this point I'd be interested
in whether he has more ideas about what could be coded using his resources - features /
plugins/ software which does not exist yet.

I don't want to prevent people from having joy. But I want to ask them whether they
want to use existing solutions first, then spend their time on new
things (which are also joyful).

> If the OP had said that he wrote it because all other package managers sucked
> then I'd have a problem with that, but it sou

> like he's doing it for fun and seeing where it's going.

He didn't use the word "suck", but he said he wants new features which the
plugin managers he had looked at don't have yet.

> I do think you have a valid point, but I think that the greatest danger here
> is quenching people in the open source community
> from doing what we do.

Live is short - too short to do something twice for the sake of doing it.
I personally was doing all the work because I was missing features. And I spent
a *lot* of time. I wished I could just have done my real job instead.
Your thinking may be different - and I accept it. So I encourage you to stop me
when thinking I'm preventing people from having joy within the vim community.
So please keep reading and commenting on the mailinglist.

[孔晓泉]

hello @Marc Weber:
Your description made　me see your's deep vimscript foundation.And
observation of things nuanced
and you and XyZ 's VAM is more power than i think
you really give some point and make me improved
but i think you take some mistakes on me and my ideal on vimapt.

>> 1.1 some plugin need out of band program to help them, such as ctag,
>> package manager should do something on it
> Can you tell me why you think it should be the "package managers task" to
> provide ctags?

sorry , i write here is "do something on it".
i not say "here i can't find ctags, vimapt come here, fix it for me"
the package manager:
1. can install the ctags (auto or ask the user before do it);
2. can give info to user like "sorry guys, i can't found ctags, make
sure you install it or in the system path var";
3. can give suggest to user like "the ctags is 404, you can use sudo
apt-get install ctags to install ctags".
above both are the meaning for "do something on it"
but which one or two or thress is/are the best "do something on it"?
i don't know.
but i think your are right at "provide ctags" is hard on so many os
and maybe some people don't like this.
so maybe one or more is(are) the best way to "do something on it", it
depands on implement and user option.
if the plugin provide the function to check environment is a good choice,
but if the package manager provide a uniform interface to handle this
job. it maybe more better.

>> 1.2 some plugin need python support or set nocompatible，but unless you
>> read the doc before, you will fall and you don't know why

here i means some plugin like "The NERD Commenter "
it had says "Make sure that you have filetype plugins enabled"
but if you don't read this and you install it, it not work or not work correct
so package manager "do something on it": give info or suggest or do
add to some vimrc file
at least do one thing on it

>> 1.4 auto-tools and interaction of other programs, let bash write
>> package name into your .vimrc is not the good path, at least i don't
>> think so.

here i means if you install some language maybe called "xxoo"
the "xxoo" language want install it's helper plugin to vim for help
you to more quick write "xxoo"
how it do it? maybe write a line to your .vimrc like this
"SomePluginManager#install('xxoo-help')"
i don't think is the good way, may the "xxoo" call a standard command
once: "InstallPackge('xxoo')" can slove this problem
i think it's more good in my ideal.

> 3. apt on vim?
>
> apt: its you calling
> apt install foo
> apt install bar

it's the biggest mistake for vimapt
vimapt is "apt on vim".it means "vimapt use apt the concept imitate,
imitate apt mechanism"
not means it's base on apt or other linux package manager software.

2013/3/11 Marc Weber <marco-...@gmx.de>:

[Marc Weber]

> but if the package manager provide a uniform interface to handle this
> job. it maybe more better.

If it was a plugin - all package managers could be used ..

> >> 1.2 some plugin need python support or set nocompatible，but unless
> >> you
> >> read the doc before, you will fall and you don't know why

You're right. But almost all .vimrc samples contain it. And this is hard
to avoid without breaking backward compatibility.
I'd vote for making "nocompatible" default instantly.

For nocomp you can check :echo &compatible
For filetype I don't know exactly - maybe somebody else know.

I personally struggeled with closing Vim coming from a Windows world
years ago, - I had trouble understand the help screen which says:

type :q<Enter> to exit

Because it didn't come to my mind that the : belongs to the keys to be
typed.
I think its more important to tell people about where to get help
(mailinglist, irc, ...) because this kind of problem is solved fast.

> [.. many lines you didn't reply to ..]
@孔晓泉: Consider removing email text you're not replying to.

Meanwhile I've also read your blog post:
http://www.howlanderson.net/?cat=33

I find this interesting:

quote:
The concept of the warehouse Provide similar linux distro warehouses
similar standardized the remote packet warehouse, provide carefully
check the package through a rigorous screening provides official
assurance (TODO: due to staffing and funding issues, is preparing for
the official repository for vim plugin)

especially:
rigorous screening provides official assurance

Do you think somebody will provide the man power to review all packages
available (or let's say most packages being used?)

Eventually vim-scripts.org could be called such a warehouse, but without
screening.

If you want to collaborate with the VAM team on some topics keep in
touch.

Yours
Marc Weber

[Marcin Szamotulski]

> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

I think this blog post nicely illustrates why we need more cooperation
on vim.org:
http://delvarworld.github.com/blog/2013/03/16/just-use-sublime-text/

Best regards,
Marcin