VAM has too outdated release on vim.org

[ZyX-I]

Opening discussion of my last suggestion (see quote) here as it is not related to issue #45.

Or, better, set up the cron job that will remove last posted archive and then post github zipball to vim.org. Posting may be borrowed from pkgdo.pl, but I did not implement removing there.

[MarcWeber]

Excerpts from ZyX-I's message of Sat Jul 16 19:22:03 +0200 2011:

Opening discussion of my last suggestion (see quote) here as it is not related to issue #45. Its only causing work to me. The install instructions talk about where to get latest version. If you want to maintain the zip I can give you my password. I could run my script. I'm too lazy. I've already told you that I'm trying to replace this all anyway. If people don't adopt .. then its another story. Most people are using git. And for those who don't want to use it we should have an abstraction layer: repos <-> compress in whatever the client can use <-> client

Marc Weber

[ZyX-I]

Its only causing work to me. The install instructions talk about where to get latest version. If you want to maintain the zip I can give you my password. I could run my script. I'm too lazy. I've already told you that I'm trying to replace this all anyway. If people don't adopt .. then its another story.

I created a script which requires you to do only three things (or four if WWW::Mechanize is not installed. If I am not mistaken it is in a package named libwww-mechanize-perl):

1. Replace strings User and Password.
2. Modify path to VAM repository (it is currently pointing to /usr/portage/distfiles/git-src/vim-addon-manager). Path must be a valid argument to --git-dir.
3. Create a cron job.

If you think it is better to have me running this script you can provide a password.

[MarcWeber]

I appreciate your efforts. But www.vim.org sucks in so much ways that I'm not going to spend any minute on it - unless users (who don't use your ebuild) complain about the zip not being up to date.

If you want to spend your time help making the new page a success. The existing one is not fixable without spending more time on it than necessary.

Feel free to create a fork of it on www.vim.org. Within 1-2 month I'll try to deprecate that all anyway. If I don't manage the move within 1-2 month you may ping me again about this.

www.vim.org has to be replaced because

• it doesn't allow collaborators
• it doesn't let you browse code
• it doesn't have a code search
• the voting system is not accurate enough and doesn't provide feedback other than "your plugin sucks" but doesn't tell why
• you can change your password

And fixing that using PHP hosting ? bad idea.

You're welcome to join: http://titanpad.com/AcUfZQjXUz

Marc Weber

[ZyX-I]

So what about using the suggested script as temporary solution before you finish the update?

[MarcWeber]

I just had a look at your script.

1) We have about 2.1 downloads each day (this month) on average. Congratulations! VAM team!

2) Your script is not good enouh because it does not increment the version number. Thus :UpdateAddons would never update VAM because the version on www.vim.org and in vim-addons/VAM/version would always match (bad idea!)

It could be fixed by using versions such as 9999.1 9999.2 ..

However there would be a second issue: If you do :UpdateAddons VAM it removes autoload RmFR before it loads it, then it fails. This could be easily fixed by providing a vam#util#Load() dummy function and calling that before rename(.

If you think that my last patches are fine I'll upload a new version. That should be up to date enough for the coming 4 weeks. And hopefully we'll have the new system then.

[ZyX-I]

Reply to message «Re: [vim-addon-manager] VAM has too outdated release on vim.org (#47)», sent 07:17:28 26 July 2011, Tuesday by MarcWeber:

Your script is not good enouh because it does not increment the version number. Thus :UpdateAddons would never update VAM because the version on www.vim.org and in vim-addons/VAM/version would always match (bad idea!)

It could be fixed by using versions such as 9999.1 9999.2 .. I suggest to put truncated hash here instead (updated version uploaded to the same link): --- repost.pl.orig 2011-07-26 07:50:39.000000000 +0400 +++ repost.pl 2011-07-26 07:52:25.000000000 +0400 @@ -76,8 +76,14 @@ my $repo = shift || '/usr/portage/distfiles/git-src/vim-addon-manager'; my $target = shift || '/tmp/vim-addon-manager-9999.zip'; my $vercom = shift || 'Zipball of branch master';

• my $version = shift || '9999';
• my $version = shift; my $vimver = shift || '7.3';
• unless($version) {
• my $G;
• open $G, '-|', git => "--git-dir=$repo", show => "--format=%h";
• ($version=readline $G)=~s/\W//s;
• close $G;
• } system git => "--git-dir=$repo", archive => "--output=$target" => "master"; -e $target || die "$target does not exist"; removeScript($scriptnr, '9999');

However there would be a second issue: If you do :UpdateAddons VAM it removes autoload RmFR before it loads it, then it fails. This could be easily fixed by providing a vam#util#Load() dummy function and calling that before rename(. Does not the same apply to updating git? I did not ever update VAM this way because I use cave for this task.

Original message:

I just had a look at your script.

1) We have about 2.1 downloads each day (this month) on average. Congratulations! VAM team!

2) Your script is not good enouh because it does not increment the version number. Thus :UpdateAddons would never update VAM because the version on www.vim.org and in vim-addons/VAM/version would always match (bad idea!)

It could be fixed by using versions such as 9999.1 9999.2 ..

However there would be a second issue: If you do :UpdateAddons VAM it removes autoload RmFR before it loads it, then it fails. This could be easily fixed by providing a vam#util#Load() dummy function and calling that before rename(.

If you think that my last patches are fine I'll upload a new version. That should be up to date enough for the coming 4 weeks. And hopefully we'll have the new system then.

[ZyX-I]

This could be easily fixed by providing a vam#util#Load() dummy function and calling that before rename(.

Why not

runtime! autoload/vam/util.vim

? I never used dummy functions.

[ZyX-I]

Does not the same apply to updating git? I did not ever update VAM this way because I use cave for this task.

Answering my own question: it should not unless RmFR was renamed in new update: git does not delete VAM files before updating.

[ZyX-I]

Answering my own question: it should not unless RmFR was renamed in new update: git does not delete VAM files before updating.

And RmFR is not called when using git.

[ZyX-I]

Why not

runtime! autoload/vam/util.vim

? I never used dummy functions.

Even more protective one:

runtime! autoload/vam/*.vim

. Should make VAM independent of any code changes that possibly happen during update.

[MarcWeber]

Changed version to look like "9999.hash" Update takes place once a day.