Re: [PATCH/RFC] git-remote-mediawiki: new tool to preview local changes without pushing

On Tue, Jun 11, 2013 at 11:31:31PM +0200, Benoît Person wrote:

I've implemented this one for now but after a real-life meeting with
Matthieu Moy we discussed the possibility to build a GitMediawiki.pm
module. It seems more "clean" than the concatenation of perl scripts.
Plus, it would force people to limit side effects inside the functions
used in this package/utils file (I have in mind the mw_connect_maybe
function here and a couple of others which directly *hope* for global
vars to be set to a nice value before being called).

What I find bad in the concatenating-thingy is the mandatory rename of
git-mw.perl into something like git-mw.unmerged.perl and
git-remote-mediawiki.perl into git-remote-mediawiki.unmerged.perl.
Otherwise, like you said, it would be hard to chain to git's Makefile
after the merge.

Yeah, I agree it's very hacky.

For now, I have really no idea which one is the best. If I may ask,
what did you have in mind while saying:

quoted

You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build procedure, and potentially be
annoying for users.

Since my previous commit (ea07ec1 in next - use Git.pm functions for
credentials), git-remote-mediawiki.perl already depends on the proper
installation of the Git.pm package. In what ways the need for the
installation of yet another package (GitMediawiki.pm) would annoy a
user ?

I was thinking that you would be self-contained inside the
contrib/mw-to-git directory, and therefore you would have to teach your
code how to install the Git module, and you could not longer just "cp
git-remote-mediawiki" into the right place to install it.

But I think we have already crossed that bridge somewhat with Git.pm.
And if you add your module as perl/Git/MediaWiki.pm and use the existing
perl build system, then it is not any extra effort from the build
system.

That is probably the most sane way to go.

-Peff