Peter l Jakobi schrieb: > On Wed, Oct 07, 2009 at 09:47:55AM +0200, Richard Pöttler wrote: >> 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).
Thanks for this. I will try it, once I got some more spare time. May I keep your address as a contact, if I get into some trouble? >> 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? The sqlite stuff is removed and the data is stored in plain textfiles. This change even saves me 10 lines of code. >> 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? Nice idea. One thing, which might get complicated is, how to determine, whether some updates for this "custom" scripts are available. Should the url be fetched and then the md5sum compared with a stored one, or the entire page (assuming it is a html page) be searched for a given pattern? How do you have it now? >>> [ 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 I think atm I store it in something simmilar: <scriptid>;<relative filenames separated by ';'> > cu & Gruesse in den nahen Sueden, > Peter (German: Gruß zurück in den anscheinend gar nicht so fernen Norden ;) ) bye richi --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
