On Wed, Oct 07, 2009 at 09:47:55AM +0200, Richard Pöttler wrote: [warning - deals more with perl and storage than vim proper, drop me a line if such discussions should be moved elsewhere after collecting the set of vim listmembers interested in it :) ]
--- > 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). Have a look at waitcond: search.cpan.org/~jakobi/ and http://perlmonks.org/?node_id=797882 I'm still uncertain wrt. turning waitcond into a module (maybe using caller to still have just one file being usable as a script) and about the 'official' namespace to use: Without doing that, you're not 'official', thus you're not visible to the bug tracker, you're not in the module lists and CPAN.pm's i /waitcond/ fails. Kobe doesn't see you. What works at this level: search.cpan.org does see you. The automated testers see and test your script. You're on cpan.org/scripts. And CPAN.pm (CPANPLUS not tested) _can_ already install you with cpan> install J/JA/JAKOBI/scripts/cliprocesses/waitcond-0.32.tar.gz (thus my assumption that it should also be able to use the meta info to pull in the modules you're using). There are a number of scripts at this level. Going further is a bit of a problem and depends on being able to actually profit from refactoring as a module. Which I don't quite see for both your script and my cpan test-case waitcond. The one example of a script going further to full official CPAN module I found is App::Ack (a perl grep rewrite, quite nice, though my own one is better [suited for me :>] ). You should be able to get to waitcond's level easy enough: - get a cpan account - add suitable pod to your script to allow it being found be the 'scripts hack' - upload via PAUSE a release as a) tarball for cpan, and b) your script only as a stand alone file for the 'scripts hack' - figure out a way to tell users about the tarball and the real home page for support files and addons (though the standalone script should be enough to get them going). === > 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. That's my own take & dislike here. Maybe make the backend used configurable? > So you want to know, what is stored in the sqlite db, or what I am doing in the sqlite itself, being lazy :) > 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. some raw ideas on reading this: allow the user to add extra info like url he fetch the script from and a second field url to watch for updates. isn't there also some script on vim.org to watch for updates to one's installed scripts? maybe clone or interface with it / talk to it's author. there's my own issue: I did modify some scripts or placed them in an out of the way location for manual use only. Maybe these fields user_hacked_the_script, user_comments_about_his_hack, user_mis-relocation And maybe code or just sketched-out-manual-procedure on how to use the information in your database to keep track of new releases while easing issues of renaming and hacked scripts. Also a way to get one's manually committed sins into the scripts database. A way to have the script detect and remark (not touch) such sins? > When removing the sqlite dependency I might come up with something more > minimal: > http://codaset.com/poettler-ric/vimscripts/tickets/12 I'd say stick to using a pre-existing module. My own impulse to just use Data::Dumper to write and read in raw perl for configuration is probably not what you want non-perl-people to be able to modify easily. YAML or windows .ini-style might be more suitable albeit repeating the fieldnames all the time. But that's an advantage in case of small datasets. CSV is a bit painful in editing as plain text and when adding fields. Shouldn't there exist DBI/DBD database backends for these formats as well? That way you can switch formats without changing your code. > This might be because my English isn't that good, but could you please > explain the last part? > > [ vimballs ] vimballs are somewhat related I'd say in tracking things a bit with an eye to making uninstalls not impossible: vimballs: http://www.vim.org/scripts/script.php?script_id=1502 "database" ~/.vim/.VimballRecord > > [(1) is certainly telling for my speed of > > safe-for-future-reference,for-now-ignore on seeing the string sqlite > > :)] [untranslated :) - : Ich habe nach dem Lesen von sqlite nur mehr den Rest nur mehr ueberflogen, da damit fuer mich klar war, dass ich es nicht einsetzen will in der Originalform. Da's aber eine gute Idee ist und spaeter mal interessant werden koennte, hab's ich ein paar Tags in Deine Mail eingebaut und es als Hinweis fuer mich archiviert.] cu & Gruesse in den nahen Sueden, Peter -- cu Peter l Jakobi [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
