create new tag
, view all tags

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:

-- 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 smile 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.


-- TimotheLitt - 2012-10-06

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2012-10-06 - TimotheLitt
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.