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:
> > 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
That is probably the most sane way to go.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html