IpPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on IpPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the IpPlugin bug database.

Feedback on IpPlugin

-- TimotheLitt - 2012-09-25

Thank you very much Timothe for contributing this plugin!

I created supporting topics IpPluginDev, IpPluginAppraisal, Support.IpPlugin and TWikibug:IpPlugin. I also tagged the plugin topic.

-- PeterThoeny - 2012-10-01

Does the plugin work in TWiki-5.x? If so please update the TestedOnTWiki field.

-- PeterThoeny - 2012-10-01

I tweeted about this:

• https://twitter.com/twiki/status/252826007009128449
• https://twitter.com/peterthoeny/status/252827410414850049

-- PeterThoeny - 2012-10-01

It has minimal dependencies on TWiki version. Yes, I verified that it runs on 5.1 trunk.

I also added an installer. Figuring out how to do this was a truly miserable experience.

I have uploaded tar and md5 files in addition to the zip files. There are no functional changes.

-- TimotheLitt - 2012-10-02

Thank you Timothe for maintaining the extensions in SVN, this makes it easier for all, including you. Sorry it was a "miserable experience" to learn the build stuff. I it is documented, but if you feel not sufficient you can enhance as needed. Feel free to ask too.

You have a ContactAuthorFirst modification policy. I'd like to help out on the plugin docs. Is it OK to do that directly in SVN?

-- PeterThoeny - 2012-10-02

I don't know about easier - midnight meetings & feature proposals to work on my own code doesn't meet my definition of that But yes, svn is a good thing (and I use it locally).

The build/create installer doc was hard to find. (BuldContrib was the best I found.) It was confusing. I had permissions problems that made the tool blow up with stack traces. (Turns out that sudo -u on all the commands helps a lot.)

The tools & doc seemed to suggest that the tools wanted to create MANIFEST/DEPENDENCIES -- and that I was supposed to create them. Never succeeded in getting the tools to do it - anyway, for IpPlugin, they were trivial to write by hand.

The tools seem to want a topic template so they can automagically add dependencies and other "variables". I never figured out to to make that work right; where the template topic lives directory? Is it supposed to be in svn, or the output? I stuck with the topic I wrote.

Testing the kit doesn't work as documented - it wants to download the old kit from twiki.org. Finally figured out that putting the kit in the directory I was supposed to be in while testing caused it to ask whether I wanted to use it. Wanted to do a test upload to my local Sandbox, as I didn't want to put anything with problems into twiki.org's revision history. Never got that to work - some random error from the tools.

"Copy from some existing plugin and modify" was less than helpful - every one I looked at had some special oddity - I couldn't tell what was required generically vs. what was unique without research. I did not want to make a lifetime study of this, I just thought I should supply an installer. I thought it was a 20 min task; I spent half a day.

The doc should have a worked-out, step by step example.

There's no reason the kit builder can't scan the sources for 'require' and 'use' to generate dependencies, including getting the version number tested with (Hint: CPAN:Module::Extract::VERSION) In fact, to show it's not difficult, here's a 1-liner that will do just that (though I don't promise that all corner cases are handled): =Run from trunk/XxxPlugin or adjust the -I accordingly: find . -name '*.pm' -exec grep -P '^\s*(require|use)\s+[A-Za-z0-9_:]+' {} \; | perl -MModule::Extract::VERSION -I`readlink -f ../core/lib` -e'my %h; while(<>){ chomp; s/\s*(?:use|require)\s+//; s/^base\s+(?:qw.|["'"'"'])([A-Za-z0-9_:]+).*$/$1/; s/^([A-Za-z0-9_:]+).*$/$1/; /^(?:warnings|strict|attributes|autouse|blib|bytes|charnames|constant|diagnostics|fields|filetest|integer|less|lib|locale|open|overload|re|sigtrap|subs|vars)/ and next; $h{$_} 1;} for (sort keys %h) {print "$_,>="; eval "require $_;"; if($@) { print $@ } else { s,::,/,g; print scalar Module::Extract::VERSION->parse_version_safely($INC{$_.".pm"});} print ",cpan,Required,Automagically extracted\n" ; }' >DEPENDENCIES.template

OK, it's ugly, but perltidy will convert it to someone's idea of beauty.

And for an initial MANIFEST: find . -type f \! -name '*~' \! -name '*,v' | sed -e's,^\./,,' -e'/\.pm$/s/$/ 0444/' -e'\,^data\/.*\.txt,s/$/ 0664/' -e'/\.pl$/s/$/ 0554/' -e'\,pub/,s/$/ 0644/' -e'\,bin/,s/$/ 0555/' -e'/MANIFEST\|DEPENDENCIES\|README/s/$/ 0444/' -e'/\.spec$/s/$/ 0444/' >MANIFEST.template

Where are the topic(s?) necessary to have a local "test upload" repository? Why, if install is supposed to be automated, doesn't it enable the plugin (if it's a simple plugin), or print out the URL for Configure (if the plugin ships with a configure extension .spec)? sed -i.bak lib/LocalSite.cfg -e'/^\$TWiki::cfg{Plugins}{XxxPlugin}{Enabled}/d' -e '/^1;/i$TWiki::cfg{Plugins}{XxxPlugin}{Enabled} = 1;'"

I kinda sorta got to something that seemed not totally wrong, and timed out.

WRT your offer to help with plugin docs: I never turn down help - but what needs doing?

If you mean the Off-line task framework, as discussed in the release meeting: I'm counting on it. (I don't think of it as a plugin.) But we should talk about the mechanism. My original idea was to keep the docs with the code - my Install has a gendoc command that (directed by MANIFEST) walks thru the sources and extracts what it thinks is doc. There are tags that specify the order in which they're to be assembled - since there are so may source files, a simple POD extract isn't enough. It may need a little refinement to separate developer from user content. Or if it ends up in more than one topic. Best way to reach me is my acm e-mail.

-- TimotheLitt - 2012-10-05

I had a few minutes while waiting for a large build... so

I added a somewhat more clever DEPENDENCIES builder to the task framework. see tools/builddep, checkin 23538. Somewhat better than the 1-liner, it knows enough to recursively scan files in a package (but not files included by the package), and it doesn't actually do an eval'd require.

It would be a good start at making building install packages easier.

It has a tendency to find more than it should; to dial it back, it consults TWiki's DEPENDENCIES and omits files shipped with the core - unless there's a conflict.

Perhaps it will save someone else some misery, while I wait for my other questions to be answered.

Enjoy.

-- TimotheLitt - 2012-10-06