The Open Repository is now back up and running again at http://svn.ali.as/cpan.
Please note there are currently NO accounts set up other than my own, but read-only service is available and you can repoint any checkouts with uncommited changes to this new URI.
My various bug fixes and new modules are not yet commited to the new repository, but I will be starting to do that now.
Some issues continue with the repository manager, preventing providing accounts to other people.
I've come to the conclusion that both Insurrection and CommitBit are to much trouble for what I want in this specific case, and that I'll have to just write my own.
Insurrection continues to be largely abandoned and impossible to install.
CommitBit seems nice enough, but is based on Jifty, and to be honest I can't help but feel that it's both too heavy (in dependency terms) for my needs. Further, installing CommitBit didn't work because at the specific time I was installing it, CPAN Jifty wasn't compatible with the CPAN Jifty::DBI, and the CPAN CommitBit wasn't compatible with SVN CommitBit... and SVN Jifty failed to install for me due to an transient SVN problem that was patched before I had a chance to ask about it.
In any case, I do get the impression that Jifty is still evolving fairly quickly, and so using something that big that is moving that fast isn't really for me.
Of course, that's a criticism entirely unrelated to the quality of Jifty itself (which seems to be improving all the time) and totally unrelated to the needs to other people or other projects. I just don't want to use it for my repository manager.
While setting up the repository, I was reminded that the SVN configuration is just an Apache .htpasswd file.
What's interesting about this is that with a fairly simple target output format, and a limited amount of data that needs to be tracked, there's really nothing preventing me from creating an "old school" style application to solve this.
A simple CGI perl script that can track accounts, send an email, and can be installed by just dropping a .pl script into a cgi-bin directory.
In fact, the style feels very very ::Tiny to me, so maybe that is actually a good approach to take?
For the moment, I'm calling my repository manager TinyAuth.
The goal, no more than 1000 lines of code, and no task ever taking more than 2 page requests from the front page, ideally only 1. And simple enough layout to work even on mobile phone browsers, so I can give people commit bits from my phone without having to get the laptop out or have a proper internet connection :)
I violate a few of the ::Tiny principles though, since I'll probably want to use a dependency or three (Email::Stuff is attractive for the email parts, and I don't really want to rely on console sendmail.
So maybe I'll end up as SimpleAuth or some other name.
But we'll see.
In the mean time, CPAN uploads of new releases of my modules (and a couple of new modules) should resume now.
I’d suggest at least adding CGI::Application or CGI::Prototype to the mix. Neither adds significant weight, except for declaring dependencies on template systems that they don’t actually need in order to function. Maybe you can also get Sam Tregar and/or merlyn to fix that.
Among template systems, Template::Simple is probably what you want. HTML::Template doesn’t have non-core dependencies either though.
Re:Just CGI.pm?
Alias on 2007-05-04T11:14:24
I won't be using a templating module, it would really just be overkill.
Instead I'm using a templating method which implements very small subset of Template Toolkit syntax... i.e. it just supports [% foo %].:)
sub template {
my $self = shift;
my $html = shift;
my $args = shift || $self->args;
foreach ( 0.. 10 ) {
# Allow up to 10 levels of recursion
$html =~ s/\[\%\s+(\w+)\s+\%\]/$args->{$1}/g;
}
return $html;
}Re:Just CGI.pm?
Aristotle on 2007-05-04T12:01:35
If that is really all you need… then go for it. But I find that even minimal scripts outgrow that functionality very quickly.
My main point was that you should take a look at the lightweight web frameworks for Perl, though. Even the tiniest apps benefit from them in my experience – as soon as you have more than 2 screens, you need to impose structure somehow. (Of course, variations of Greenspun’s 10th Rule apply to many things. You could build a rudimentary framework in situ – much like how CGI::Protoype got started…)
Re:SVN::Web plugin?
Alias on 2007-05-04T11:02:49
I don't want to do this mainly because by having it as a standalone application I can potentially reuse it in situations other than SVN. Initially, anything else that runs off a.htpasswd file (like protected directories and WebDAV shares) but later there's some potential to add other targets (what, I'm not sure yet).
