Re: pyblosxom future (1.3/2.0)

On Mon, 28 Mar 2005, Doug Ransom wrote:
> 
> I just joined after the * pyblosxom future (1.3/2.0)* announcement by 
> Will.
>
> I propose for 1.3, the entire pyblosxom code base and a good chunk of 
> the contrib package be provided with unit tests, so they can be 
> refactored.  This would make it way easier for people to add or refactor 
> code.

That would be really great if that could happen.  If you want to take the 
lead on that, I'm all for it and will help where I can.  If you don't want 
to take the lead on that and no one else volunteers to take the lead, then 
it won't happen.

Just to put this in a historical context, we've been wanting a test suite 
and test system for a while now but it's never happened because no one has 
done it.  I'm sure it'd help a lot--no one's disupting that.  The issue is 
that no one has had the time (or expertise--there's nothing trivial about 
setting up a solid test suite and test system) to do it thus far.

I think Bill Mill developed some code to do timing tests on PyBlosxom as 
well as a script that generates random entries.  The information is 
probably in the mailing list archives somewhere.


> For example, I am struggling with the pycategories code.  I would like 
> different html output, and I cannot figure out how to run/debug the code 
> without hitting a webserver (I could probably fake a cgi call with 
> komodo, but thats not much better).

I plan on looking at the pycategories, pyarchives, and pycalendar code 
which were written over a year ago and could probably use some updating at 
this point.  Especially since our required Python version is now 2.2. 
Someone recently mentioned a bug in pycategories that I'd like to fix. 
So looking into those three plugins (all of which I think I wrote or had a 
big hand in writing) are on my hit list of things to do soonish.  If 
someone gets to it first, that'd be super.


> It would be cool to have a shipping blog with predefined entries, 
> directories, etc., and a way to test/debug any of the plugins. I think 
> this would also be a good time to switch to python 2.4 and allow the 
> code to use any newer features.

There's no reason someone can't take what we've done with the core and 
contrib packages and extend that a little further into a completely 
configured blog package with flavours and plugins and whatnot.  I think 
that's the route I would prefer since it takes the onus off of my back to 
do it.

In regards to switching to 2.3/2.4, we had a discussion about it at the 
end of February that pretty much covers the issue in a nutshell and where 
I stand on it:

http://article.gmane.org/gmane.comp.web.pyblosxom.devel/1408

It waters down to the idea that I want a pressing need to up the 
requirement from 2.2 to 2.3/2.4 because I don't think there's a really 
good reason to be aggressive with our Python version requirement.  From a 
user's perspective, the fewer hurdles they have for installing and using 
PyBlosxom, the better off they are.

That's my position.  I'm definitely still willing to hear other thoughts 
on the issue.  Any decision making will (hopefully) take into account:

  1. new things we can do with PyBlosxom we couldn't do with previous
     Python versions
  2. availability of the version of Python we're thinking of requiring
  3. how much of our user base (theoretical or otherwise) this will
     affect
  4. the profile of our targetted user


At this point, I'm just waxing philosophical....

Woah!  Firefox on my Windows laptop just updated itself.  Trippy!

/will



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click