Peter l Jakobi schrieb: > On Tue, Oct 06, 2009 at 01:48:32PM +0200, Richard Pöttler wrote: >>> I think that means lots of folks will pass on trying to test or use >>> your script. Too bad, too because it looks like you put a fair bit of >>> effort into it. > ... >> Would you mind installing Archive::Extract, Config::General and >> File::Fetch (which is included in perl 5.10), or is it an absolute no-go? > > Maybe add some boilerplate CPAN.pm commands to update them, plus an > apt-get/aptitude/yum command in case some of these are packaged on one > of more of the larger distros (but I'd probably restrict that myself > to just debian or ubuntu).
Nice idea. I will try to figure something out. > Furthermore AFAIR CPAN.pm can deal with dependencies. When using an > (in)official CPAN dist tar ball, shouldn't it take care of fetching > listed prerequisites as well from? Which means to put the script on > cpan in addition to the script section of vim.org. I have never messed with CPAN.pm, but I will check, whether something like that is possible. Putting the script into the scripts section on www.vim.org is also a good Idea (to be honest, I never thought about that). > My own take: > > first look: > - code looks clean. > - ton of modules (which is both good and bad, but given we're talking > vim and a user's customized .vim/, there's no need to keep this a > standalone script). > - sqlite. > > The use of sqlite was what made me say: might be a nice idea, won't > use it. > > IMHO we're dealing with vim and text. So I'd really prefer the > database format to be a textfile as well. Instead of making it into > the 3-jump sqlite3 something-dump-or-other; vi ; sqlite3 > something-recreate-new-db-or-other. If I got you right, you want to get rid of sqlite? This is fine for me, I just wanted to try it out some time, so I took this as an opportunity. A solution is already at my mind, just got to be implemented. > Final note: > > If not already documented: > > (1) I'd like to know what the script is actually doing and storing in > addition to just replicating the information from the file system > (maybe something like version information, user changes, URL location > for updates). Might be already part of the docs, might be for the > wishlist. So you want to know, what is stored in the sqlite db, or what I am doing during the installation of a script? In the sqlite db I store all information of all searched scripts until now (id, author, type, summary, installed version and so on) and the installed files. Sure, this is much unneccessary information, but i thought it would be better to store too much, instead too less. When removing the sqlite dependency I might come up with something more minimal: http://codaset.com/poettler-ric/vimscripts/tickets/12 During the installation of a script I simply fetch the lastest version, try to extract the files of whatever I got, and create the helptags. I will put that information into the help command, or the readme (not sure, where it will fit best). > (2) The vimballs already retain some information of installed scripts; > depending on size, speed and use-frequency, something similar might > suffice. > > > [(1) is certainly telling for my speed of > safe-for-future-reference,for-now-ignore on seeing the string sqlite > :)] This might be because my English isn't that good, but could you please explain the last part? bye richi --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
