Re: finishing up PyBlosxom 1.5

On 01/05/2010 10:07 AM, chombee wrote:
> I've checked it out from sourceforge and played around with it. Really
> good work! I love that I was able to do just:
>
>      pyblosxom-cmd create ./blog
>      cd blog
>      paster serve blog.ini
>
> and then I was looking at a new blog running in a local paste webserver.
> And this was all very clear from the documentation, which seems to have
> improved a lot.

This ease of throwing a blog together makes it much easier to test blog 
configurations and plugins, too.  Also, it makes it easier to document.


> I'm also a big fan of the new truncate_* config variables.

I fixed that specifically for you.  :)


> And I really like the pyblosxom-cmd and that it looks like (from the
> docs) plugins can integrate with it. There's a whole bunch of 'utility'
> plugins in the plugin registry that are really standalone command-line
> scripts and not plugins at all, they could now be integrated into
> pyblosxom-cmd.

I think we could move some of the utility functions into the core and 
the others should become plugins that expose commands.  I think this 
should make things a lot easier to deal with for users.  I know it's 
made it much easier for me.


> I agree with moving off SourceForge, it's really not a very good site. I
> like git so I'd probably be happy with gitorious or github. However bzr
> is a distributed VCS with about the same feature-set of git, and
> launchpad.net (a bzr source code hosting site) offers features that may
> be very useful to Pyblosxom and may be missing from github and
> gitorious. I'm thinking of its support for bug tracking, code reviews,
> translations, mailing lists, question&  answer tracking and FAQs,
> specification tracking, maybe even the automated Ubuntu package
> building. It's all stuff I've never wanted for my own little scripts
> (which are on github) but that might be useful for a bigger project with
> a community, like Pyblosxom.  It's these community project features that
> launchpad seems to excel at. As far as I know both github and gitorious
> (and I think bitbucket) offer only minimal features of this kind, e.g.
> they will give your project a wiki but not much else, but the advantage
> they have over launchpad is simplicity and directness.

I think I'm going to split the project site from where the code is 
hosted.  I'll probably host the project site on my server (bluesock.org) 
and put the code somewhere else.

I'm a git person now and I think I want to host the code on gitorious. 
I'm using git for everything else in my world right now and gitorious is 
Free Software.  I've recently created a gitorious account and I'm toying 
with the system.  I haven't run into anything that I consider a 
showstopper yet.

Launchpad is really cool, but I'd rather go with git over bazaar.

I don't plan to move the code anywhere until after PyBlosxom 1.5 is out.


> Does Pyblosxom still use the contributed plugins package? I thought that
> had been dropped some time ago in favour of plugins being self-hosted by
> the plugin authors, and merely linked to from the plugin registry on the
> pyblosxom site?
>
 > <...soliloquy on sad state of plugins snip...>

Plugins are really important to PyBlosxom.  I think I made a mistake a 
while back when splitting plugins out of the PyBlosxom core release and 
into a contributed plugins pack.  Having said that, I still like my 
reasoning at the time and I'd probably do it again.

Regardless, I think it's time to ship plugins with PyBlosxom again.  A 
few of us have been talking about this on IRC over the last few days and 
I think the consensus is this:

1. create a "plugins" directory with plugins that are well maintained, 
have unit tests, and are known to work with PyBlosxom that get shipped 
with the PyBlosxom tarball in a release.

2. keep the "contrib" directory for all the plugins that haven't yet 
been overhauled, aren't as well maintained, and also cache plugins that 
are in the registry that are created by other people.

3. when I host the site on bluesock.org, I'll be able to have an 
interactive registry again that allows people to add plugins, update 
plugins, comment on plugins, ...  and this will prevent the incredible 
registry rot we've got now.

This solves the following problems:

1. when someone downloads PyBlosxom, they get a bunch of plugins that 
will work and are known good.

2. we maintain copies of plugins out there in the community even if the 
members disappear.  thus the plugin registry doesn't end up with dead 
entries.

3. a useful and updateable registry that doesn't depend on a single 
person to update.

I'm planning to tackle some of this for PyBlosxom 1.5, but I don't want 
to sit on the release for too long, so I think I'll create the "plugins" 
directory, overhaul a basic set of plugins, and leave the rest as is 
until PyBlosxom 1.6.

That's the plan.  The last week has been a good development week, so I'm 
excited about the plan.

Join us on #pyblosxom on irc.freenode.net -- it's been fun the last few 
days.

/will

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev