pyblosxom-devel — Development Mailing List for pyblosxom

[Pyblosxom-devel] yeararchives (2)

[Sebastian S. <Seb...@SS...>]

Next issue with yeararchives and static rendering:

The yeararchives plugin creates URLS (thus files) called: 2003 2004
.... (not appending any .flavour appendix by the way)

The regular pyblosxom renderer creates files like /2003/index.snarfed
which will fail as 2003 is already a regular file created by
yeararchives.

This could be solved by:
1) having pybloxom renderer not create yearly index files. I have 
   py["static_monthnames"] = 0
   py["static_monthnumbers"] = 0
   in my config.py. Why not also have a py["static_year"] = 0 that
   disables this by default?

2) The yeararchives plugin should create .flavor files to not clash with
the year directories, ie if yeararchives created /2003.snarfed the
/2003/index.snarfed could exist just like it does today without
interfering.

2a) For this to work, the yeararchive plugin would need to understand
URLS such as /2003.snarfed which it does not now. If the URL is not
^/2003$ it won't recognize it. Here is a patch that drops of final
flavour bits, although I am not sure if that is the correct thing to do
here or if there are better ways. I have implemented that and can send
the patch if needed.

Separately, I am going to send a patch that implements the
cb_staticrender_filelist callback for the yeararchives plugin.

Sebastian

Re: [Pyblosxom-devel] Parser Fragility

[will kahn-g. <wi...@bl...>]

I think this looks ok but it'd be good to provide a test in the test
suite for it.

So, if you want, you could push the test with the fix or alternatively,
I can take some time to write a test.

Also, this reminds me of this issue:

title
#tags foo
#tags foo2
body

I should document that.  What happens is the second #tags value
overrides the first--there's no multidict thing going on here.

/will


On 05/04/2010 05:16 AM, Sebastian Spaeth wrote:
>> This happens when parsing the #meta data in blog posts, I think. It
>> absolutely expects to find something after a "#foo " or it will break. I
>> think we should make pyblosxom a bit more robust, an empty #tags set for
>> example might be uncommon but no reason to make pyblosxom crash.
> 
> OK, so lets test our new tools. Here is my proposed fix:
> 
> http://gitorious.org/pyblosxom/spaetz-pyblosxom/commit/3e5e3335ba766d43115f984cc4ace7ea0930f4b4
> 
> which resolves the crash for me.
> 
> All it does is use "" as #meta value if there is none given.
> 
> The commit is in my clone:
> git clone git://gitorious.org/~spaetz/pyblosxom/spaetz-pyblosxom.git
> in the "robustify-parser" branch.
> 
> Should I commit this to the regular master branch or do you want to pull
> cherry pick from here?
> 
> Sebastian
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] tags plugin

[will kahn-g. <wi...@bl...>]

Whoops--that's my fault.  You're right--this should be a KeyError and
not an AttributeError.

I'm +1 on your suggested fix.


On 05/04/2010 05:38 AM, Sebastian Spaeth wrote:
> 
> The current tags plugin in git uses this code:
> 
>     try:
>         flavour = form["flav"].value
>     except AttributeError:
>         flavour = config.get("default_flavour", "html")
>     baseurl = config.get("base_url", "")
>     trigger = config.get("tags_trigger", "tag")
> 
> However, it raises KeyError, not AttributeError for me when no
> ?flav=html is appended, crashing the cgi process.
> 
> Is AttributeError really the right thing to use here? Otherwise let's
> except KeyError only. THis fixes it and makes my blog work.
> 
> THanks for applying or do you want me to push? (or provide a patch to
> pull?)
> 
> Sebastian
> 
> P.S. I think both fixes from today should still go in before we declare
> 1.5 as ready.
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] Yeararchives question

[will kahn-g. <wi...@bl...>]

That's my fault, too.  I only recently converted wbgarchives to
yeararchives.  The former was a hack for my site.  The latter should be
less hacky.

I think in this case we want to specify the flavour.  It shouldn't be
hardcoded to html, but it should be the flavour the user is currently
viewing the site with.  You actually just fixed an issue with this very
thing in the tags plugin.  The fix for this plugin should be similar to
that section of the tags plugin.

Also, we should probably make the template configurable like we did with
the category and tags plugins.

/will


On 05/04/2010 09:22 AM, Sebastian Spaeth wrote:
> First of all, the yeararchives is great, exactly what I need. Second,
> permalinks on the single pages are constructed 
> 
>    l = ("(%(path)s) <a href=\"" + baseurl +
>          "/%(file_path)s.html\">%(title)s</a><br>")
> 
> 
> which hardcodes the .html flavour, which I don't use for example.
> 
>    l = ("(%(path)s) <a href=\"" + baseurl +
> -         "/%(file_path)s.html\">%(title)s</a><br>")
> +         "/%(file_path)s\">%(title)s</a><br>")
> 
> If you agree please pull the above patch from my spaetz-pyblosxom.git
> repo in the archive-flavour branch which contains only this patch over
> master.
> 
> Just using the base URL will pick whatever default flavor we have
> chosen, which is certainly what we want to use here.
> 
> Sebastian

[Pyblosxom-devel] Yeararchives question

[Sebastian S. <Seb...@SS...>]

First of all, the yeararchives is great, exactly what I need. Second,
permalinks on the single pages are constructed 

   l = ("(%(path)s) <a href=\"" + baseurl +
         "/%(file_path)s.html\">%(title)s</a><br>")


which hardcodes the .html flavour, which I don't use for example.

   l = ("(%(path)s) <a href=\"" + baseurl +
-         "/%(file_path)s.html\">%(title)s</a><br>")
+         "/%(file_path)s\">%(title)s</a><br>")

If you agree please pull the above patch from my spaetz-pyblosxom.git
repo in the archive-flavour branch which contains only this patch over
master.

Just using the base URL will pick whatever default flavor we have
chosen, which is certainly what we want to use here.

Sebastian

[Pyblosxom-devel] tags plugin

[Sebastian S. <Seb...@SS...>]

The current tags plugin in git uses this code:

    try:
        flavour = form["flav"].value
    except AttributeError:
        flavour = config.get("default_flavour", "html")
    baseurl = config.get("base_url", "")
    trigger = config.get("tags_trigger", "tag")

However, it raises KeyError, not AttributeError for me when no
?flav=html is appended, crashing the cgi process.

Is AttributeError really the right thing to use here? Otherwise let's
except KeyError only. THis fixes it and makes my blog work.

THanks for applying or do you want me to push? (or provide a patch to
pull?)

Sebastian

P.S. I think both fixes from today should still go in before we declare
1.5 as ready.

[Pyblosxom-devel] Parser Fragility

[Sebastian S. <Seb...@SS...>]

Hi Will,

I was just testing the latest pyblosxom git on my existing blog entries
and they die:

File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/pyblosxom.py", line 439, in run_pyblosxom
     p.run()
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/pyblosxom.py", line 165, in run
     blosxom_handler(self._request)
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/pyblosxom.py", line 925, in blosxom_handler
     renderer.render()
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/renderers/debug.py", line 115, in render
  escv(content.get('filename', 'No such file\\n')))
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/entries/base.py", line 279, in get
  return self.__getitem__(key, default)
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/entries/base.py", line 257, in __getitem__
  return self.get_metadata(key, default)
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/entries/fileentry.py", line 96, in get_metadata
  self._populatedata()
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/entries/fileentry.py", line 151, in _populatedata
  entrydict = eparser(self._filename, self._request)
File "/home/spaetz/sspaeth.de/pyblosxom/Pyblosxom/pyblosxom.py", line 970, in blosxom_entry_parser
     entry_data[meta[0].strip()] = meta[1].strip()
IndexError: list index out of range

This happens when parsing the #meta data in blog posts, I think. It
absolutely expects to find something after a "#foo " or it will break. I
think we should make pyblosxom a bit more robust, an empty #tags set for
example might be uncommon but no reason to make pyblosxom crash.

Also, I happened to run the tags plugin with the command categoriestotags
previously which inserted loads of "#tags \r" lines, which caused above
crash to occur. Should the category plugin try to insert empty #tags
lines?

Sebastian

Re: [Pyblosxom-devel] Parser Fragility

[Sebastian S. <Seb...@SS...>]

> This happens when parsing the #meta data in blog posts, I think. It
> absolutely expects to find something after a "#foo " or it will break. I
> think we should make pyblosxom a bit more robust, an empty #tags set for
> example might be uncommon but no reason to make pyblosxom crash.

OK, so lets test our new tools. Here is my proposed fix:

http://gitorious.org/pyblosxom/spaetz-pyblosxom/commit/3e5e3335ba766d43115f984cc4ace7ea0930f4b4

which resolves the crash for me.

All it does is use "" as #meta value if there is none given.

The commit is in my clone:
git clone git://gitorious.org/~spaetz/pyblosxom/spaetz-pyblosxom.git
in the "robustify-parser" branch.

Should I commit this to the regular master branch or do you want to pull
cherry pick from here?

Sebastian

[Pyblosxom-devel] Fix for link in documentation

[Sebastian S. <Seb...@SS...>]

 You can find plugins in the `PyBlosxom plugin registry`_.
 
-.. _PyBlosxom plugin registry: http://pyblosxom.sourceforge.net/blog/registry/
+.. _PyBlosxom plugin registry: http://pyblosxom.sourceforge.net/registry/
 
 Additionally, some people write plugins, but never register with the plugin 
 registry. Sometimes this is because the author doesn't feel the plugin is 

Re: [Pyblosxom-devel] jinja2 as renderer

[will kahn-g. <wi...@bl...>]

I think this is awesome and (weirdly) had a dream about writing a jinja2 
renderer last night.  Seriously.  Really weird.

It'd be good to support the blosxom renderer callbacks in the jinja2 
renderer because then it's more likely plugins will "just work". 
Otherwise, you (or someone else) will have to create jinja2 versions of 
plugins.  Definitely worth looking into some more.

jinja2 (or any templating engine, really) would solve a ton of problems 
we have with the blosxom renderer and would probably make templating 
easier.  I just wish we didn't have to go re-write a lot of stuff to 
switch to it.

I don't have time to look into it more this week (slurping PyCon video, 
pushing out Miro 3.0, writing a User Manual for Miro 3.0, ...), but I've 
got it in my list of things to do soon.


On 02/24/2010 08:26 AM, Sebastian Spaeth wrote:
> Hi all,
>
> as I wanted to learn more about the pyblosxom architecture, I coded a
> Renderer plugin that uses jinja2 as a renderer. jinja2 is an excellent
> templating system that gives you lots of functionality and closely
> resembles the style in django web apps.
>
> I put it up here: http://bitbucket.org/spaetz/pyblosxom_blog/
> You can clone it with hg clone
> https://spaetz@bitbucket.org/spaetz/pyblosxom_blog/
> (it contains all my private blog posts, sorry for that :))
>
> All the changes are in 6 commits from
> 5abac1380cd7 .. 5eea5ffa0b60
> Most of them are amazingly trivial.
>
> It can be turned on by just loading it as a plugin and setting
> py['renderer']='jinja2' in your config.py (of course you need to have
> jinja2 installed). And you also need the corresponding template files in
> <datadir>/flavours/jinja/<flavor>.flav. In one of the above commits I
> add template files for atom, rss20, snarfed (html based on snarfed but
> heavily modified).
>
> What breaks:
> - I had problems with non-ascii chars in filenames, using
> python2.5. UTF-8 in posts works fine though.
> - I am a bit unsure which callback will break when you switch away from
> the blosxom renderer though. The cb_story one will break for sure (I
> added a cb_jinja2 one though that plugins can use).
> - I don't have beautiful documentation written for it.
>
> Why do I like it?
> - I like the templating language. It is powerful and easy to understand
> - One template for stories that inherits from base templates, rather
> than concatenating lots of individual templates.
>    For example, this let me set set the 'title' in<head>  in a story
>    view. Usually the story title is only available in the story
>    template at which time it is too late to manipulate<head>.
> - It was amazingly simple to plug in a new Renderer.
> - I learned a lot while coding it :)
>
>
> If you find it useful, have fun. Otherwise sorry for the noise.
>
> Sebastian
>
> P.S. You can see it in action at http://sspaeth.de/ (some German, some
> English posts).
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>

[Pyblosxom-devel] jinja2 as renderer

[Sebastian S. <Seb...@SS...>]

Hi all,

as I wanted to learn more about the pyblosxom architecture, I coded a
Renderer plugin that uses jinja2 as a renderer. jinja2 is an excellent
templating system that gives you lots of functionality and closely
resembles the style in django web apps.

I put it up here: http://bitbucket.org/spaetz/pyblosxom_blog/
You can clone it with hg clone
https://spaetz@bitbucket.org/spaetz/pyblosxom_blog/
(it contains all my private blog posts, sorry for that :))

All the changes are in 6 commits from
5abac1380cd7 .. 5eea5ffa0b60
Most of them are amazingly trivial.

It can be turned on by just loading it as a plugin and setting
py['renderer']='jinja2' in your config.py (of course you need to have
jinja2 installed). And you also need the corresponding template files in
<datadir>/flavours/jinja/<flavor>.flav. In one of the above commits I
add template files for atom, rss20, snarfed (html based on snarfed but
heavily modified).

What breaks:
- I had problems with non-ascii chars in filenames, using
python2.5. UTF-8 in posts works fine though.
- I am a bit unsure which callback will break when you switch away from
the blosxom renderer though. The cb_story one will break for sure (I
added a cb_jinja2 one though that plugins can use).
- I don't have beautiful documentation written for it.

Why do I like it?
- I like the templating language. It is powerful and easy to understand
- One template for stories that inherits from base templates, rather
than concatenating lots of individual templates.
  For example, this let me set set the 'title' in <head> in a story
  view. Usually the story title is only available in the story
  template at which time it is too late to manipulate <head>.
- It was amazingly simple to plug in a new Renderer.
- I learned a lot while coding it :)


If you find it useful, have fun. Otherwise sorry for the noise.

Sebastian

P.S. You can see it in action at http://sspaeth.de/ (some German, some
English posts).

Re: [Pyblosxom-devel] New syntax for metadata?

[chombee <ch...@la...>]

On Sat, Feb 20, 2010 at 04:53:01PM -0500, will kahn-greene wrote:
> On 02/20/2010 04:03 PM, chombee wrote:
> > Maybe a suggestion for 2.0? Or, this could perhaps be implemented as a
> > plugin first as a test and then maybe integrated into 2.0 later.
> >
> > Pyblosxom's entry metadata is a neat feature but in my humble opinion
> > the syntax is a little ugly and non-standard.  Here's an example of what
> > I'm talking about:
> >
> >      This is my first post
> >      #mood bored
> >      #music The Doors - Greatest Hits Vol 1
> >
> >      This is the beginning of the body of my post...
> >
> > The most standard, recognisable use of words beginning with a # like
> > that is as tags in twitter, identica etc., not as key: value pairs.
> 
> PyBlosxom and Blosxom both predate Twitter and Identi.ca.  I don't think 
> that this is adequate argument that the metadata syntax is non-standard.

What, you mean that I think it looks nicer isn't enough? :) But
seriously, I don't think that pyblosxom predates twitter and identica
(and possibly YAML also) is any reason not to modernise. Forget that
#mood looks to me like a hash-tag. The more important point is that
'#mood bored' does _not_ look to me like a key, value pair. A more
common syntax for key, value pairs, as used in email headers, YAML,
JSON, Python, Ruby and others, is 'mood: bored'. This syntax has become
popular for good reason: it's very readable, it's close to a common
construction used in natural English, it's simple and unambiguous to
parse, etc. Maybe it's just me, but the # syntax just seems a little
arbitrary.

> > It's also very limited. Metadata keys cannot contain spaces, and
> > metadata values can only be one line long. I'd suggest an
> > alternative syntax: [snip]
> 
> What are the compelling use cases for spaces in metadata keys and
> metadata values that are longer than a line?  Have there been things
> you haven't been able to do with the existing format?

Spaces in keys is a small thing, but it would be nice. As for multiple
lines, I think there are lots of things that I might want to put in
metadata that might use it. For example, say I want to put a summary of
each post in its metadata and I'll write my flavours such that the
summaries and not the full contents are used in the RSS feed, and on the
index pages. So I add a #summary tag. But my summary is limited to one
line, I can't hard-wrap it in my editor and I can't use multiple
paragraphs in my summary. I'm sure there are other things you might want
to do, basically whenever you want a post to have something that's more
than one line that isn't the body of the post. My tumblelog plugin ran
into this problem also, which is why I had to write a new entry parser
for it.

If I have time I may do some plugin hacking soon and see what comes off
it.

Re: [Pyblosxom-devel] New syntax for metadata?

[will kahn-g. <wi...@bl...>]

On 02/20/2010 04:03 PM, chombee wrote:
> Maybe a suggestion for 2.0? Or, this could perhaps be implemented as a
> plugin first as a test and then maybe integrated into 2.0 later.
>
> Pyblosxom's entry metadata is a neat feature but in my humble opinion
> the syntax is a little ugly and non-standard.  Here's an example of what
> I'm talking about:
>
>      This is my first post
>      #mood bored
>      #music The Doors - Greatest Hits Vol 1
>
>      This is the beginning of the body of my post...
>
> The most standard, recognisable use of words beginning with a # like
> that is as tags in twitter, identica etc., not as key: value pairs.

PyBlosxom and Blosxom both predate Twitter and Identi.ca.  I don't think 
that this is adequate argument that the metadata syntax is non-standard.

> It's
> also very limited. Metadata keys cannot contain spaces, and metadata
> values can only be one line long. I'd suggest an alternative syntax:
> [snip]

What are the compelling use cases for spaces in metadata keys and 
metadata values that are longer than a line?  Have there been things you 
haven't been able to do with the existing format?

I agree that this would be a good thing to test out in an entry parser 
plugin, work with other people who are like-minded, see what issues are 
involved, and then see if it gains traction amongst PyBlosxom users.

/will

[Pyblosxom-devel] New syntax for metadata?

[chombee <ch...@la...>]

Maybe a suggestion for 2.0? Or, this could perhaps be implemented as a
plugin first as a test and then maybe integrated into 2.0 later.

Pyblosxom's entry metadata is a neat feature but in my humble opinion
the syntax is a little ugly and non-standard.  Here's an example of what
I'm talking about:

    This is my first post
    #mood bored
    #music The Doors - Greatest Hits Vol 1

    This is the beginning of the body of my post...

The most standard, recognisable use of words beginning with a # like
that is as tags in twitter, identica etc., not as key: value pairs. It's
also very limited. Metadata keys cannot contain spaces, and metadata
values can only be one line long. I'd suggest an alternative syntax:

    This is my first post
    mood: bored
    music: The Doors - Greatest Hits Vol 1

    This is the beginning of the body of my post...

I think this both looks nicer and looks more like key: value pairs, and
it's a more standard and familiar syntax. It's YAML syntax, in fact.
Also, it remains easy for pyblosxom to parse and it won't make writing
posts any more complicated for the user.

If the second line of the file contains a : character then it's
considered a metadata line, and any lines immediately following it that
also contain a : are metadata too. The first line after the title that
does not contain a : marks the beginning of the body. This could be an
empty line (which would disambiguate things if you wanted the first line
of content to contain a : character).

To parse it just split each metadata line at the first : character to
get the key and value, so keys can contain spaces (but they can't
contain : characters).

Based on YAML syntax you could extend this idea to allow multi-line and
structured metadata blocks. In fact, you could use PyYAML to parse the
metadata block once pyblosxom's parser has identified the block and
split it out from the rest of the file contents. PyYAML would return a
dictionary to pyblosxom, just as pyblosxom currently parses metadata
blocks as dictionaries. Parsing the metadata block as YAML would allow
you to do lots of things, though admittedly it might make the
implementation a little more complicated.

Lists, either on multiple lines or on one:

    This is my first post
    key:
     - value 1
     - value 2
    another key: [value 1, value 2]

    This is the body...

I can see lists being useful for plugins that implemented tags.

(The multi-line list is delimited by indentation.)

Nested structure:

    This is my first post
    key:
      key: value
      key: value
      key: value
    key:
      key: value

    This is the body...

(Again indentation denotes structure here, following YAML syntax.)

Multi-line values:

    This is my first post
    key:
      blah blah blah blah blah blah
      blah blah blah blah blah blah
      blah blah blah blah blah blah

      blah blah blah blah blah blah
      blah blah blah blah blah blah

    This is the body...

I can see multi-line support being useful for plugins that implement
entry summaries, for example.

(Again, indentation delimits the multi-line value. In this case the
first empty line of the file and several other lines that do not contain
: characters are part of a metadata value and do not mark the beginning
of the entry's body, and this is unambiguous because indentation is
used.)

PyYAML will parse values 'true' and 'false' as python booleans, integer
values as integers, floating point values as floats, YAML lists as
python lists, YAML mappings as python dictionaries, even timestamp
strings in various formats as standard python datetime objects (e.g. for
storing publication times in metadata).

Note that because of the way PyBlosxom would identify the metadata block
(by looking for lines containing : characters) before passing it to YAML
for parsing, I believe the top-level object in the YAML document would
always be a YAML mapping, which PyYAML would parse to a python
dictionary. So it's a slightly restricted YAML that I'm suggesting. I
believe YAML documents generally may have a list as the top-level
object. Simply looking for lines that contain :'s is probably not enough
to guarantee that you've found a YAML document whose top-level object is
a mapping, it would probably be slightly trickier in practice.

Re: [Pyblosxom-devel] pyblosxom 1.5 status -- almost there

[will kahn-g. <wi...@bl...>]

On 01/26/2010 04:02 AM, Sebastian Spaeth wrote:
> On 01/25/10 17:15, will kahn-greene wrote:
>> I did a lot of work over the weekend to pull in plugins and tests from
>> contrib into the new plugins directory.  I haven't done a lot of testing
>> beyond this, but I think I'm done with the crux of the plugin overhaul
>> work for now.
>
> Cool, thanks a bunch Will. I had one issue cropping up with respect to
> wbgarchives and static rendering. Rendering statically, lead to archive
> pages that contained the full blog posts (and not the nicer wbgarchives
> summary pages), I had to add the extra URLS ['/2010/','/2009/,etc] to
> config.py in order to get those rendered too (and some RewriteRule
> trickery to get the resulting pages shown. Would it be possible to get
> the /year/ pages rendered by default when I have wbgarchives active?
> I have solved the issue for now with my extra pages, but it's not a very
> 'clean' solution.

I know I've thought about this issue.  Static rendering needs to be able 
to ask plugins for additional urls to render.  I don't think anything 
has been implemented to fix it, though.

I'll put that on the list of things to look into for 1.6.

Incidentally, the rough TODO list is in the TODO file.

/will

Re: [Pyblosxom-devel] pyblosxom 1.5 status -- almost there

[Sebastian S. <Seb...@SS...>]

On 01/25/10 17:15, will kahn-greene wrote:
> I did a lot of work over the weekend to pull in plugins and tests from
> contrib into the new plugins directory.  I haven't done a lot of testing
> beyond this, but I think I'm done with the crux of the plugin overhaul
> work for now.

Cool, thanks a bunch Will. I had one issue cropping up with respect to 
wbgarchives and static rendering. Rendering statically, lead to archive 
pages that contained the full blog posts (and not the nicer wbgarchives 
summary pages), I had to add the extra URLS ['/2010/','/2009/,etc] to 
config.py in order to get those rendered too (and some RewriteRule 
trickery to get the resulting pages shown. Would it be possible to get 
the /year/ pages rendered by default when I have wbgarchives active?
I have solved the issue for now with my extra pages, but it's not a very 
'clean' solution.


Sebastian

[Pyblosxom-devel] pyblosxom 1.5 status -- almost there

[will kahn-g. <wi...@bl...>]

I did a lot of work over the weekend to pull in plugins and tests from 
contrib into the new plugins directory.  I haven't done a lot of testing 
beyond this, but I think I'm done with the crux of the plugin overhaul 
work for now.

I'm going to update my blog again to do some "real world" testing of the 
1.5 code and plugins.  I'll let that sit for a bit while I do one last 
pass through the documentation.

I hope to do a pyblosxom 1.5 release some time this week.

Then I'll update the web-site.

If you've got outstanding pyblosxom issues that aren't addressed in 
trunk right now, now's the time to bring them up.

/will

Re: [Pyblosxom-devel] finishing up PyBlosxom 1.5

[chombee <ch...@la...>]

Hey Will,

Since your activity with 1.5-dev I've started using pyblosxom again, the
dev version, and even beyond what I've already said in my previous
email, there is just a lot of nice changes since 1.4.3! For example, it
didn't used to be possible to have config.py somewhere other than in the
same directory as pyblosxom.cgi, did it? But this ability makes things
much smoother for my particular use case. The default pyblosxom.cgi and
config.py have really been cleaned up a lot, which is very helpful.
Really, it feels much nicer than it used to, and I think this has a lot
to do with little things, attention to detail. Good work!

[Pyblosxom-devel] path variable in story template

[Sebastian S. <Seb...@SS...>]

I have the problem in current 1.5 trunk that my categories in the feed
start with a '/', e.g. "/Private" and have tracked down the problem. The
tag is defined by the 'path' template variable which is set in
fileentry.py and I found it's calculation to be a bit weird. Please find
below a patch that makes it a bit prettier and actually removes the
initial slash. Please apply if this looks ok to you.


diff -r 7c8cb08f38eb pyblosxom/Pyblosxom/entries/fileentry.py
--- a/pyblosxom/Pyblosxom/entries/fileentry.py	Mon Jan 18 09:34:41 2010 +0100
+++ b/pyblosxom/Pyblosxom/entries/fileentry.py	Wed Jan 20 11:34:40 2010 +0100
@@ -128,19 +128,13 @@
         We then parse the file and fill in the rest of the information
         that we know.
         """
-        file_basename = os.path.basename(self._filename)
+        (path, file_basename) = os.path.split(self._filename)
+        path = path.replace(self._root,'')
+        if path.startswith(os.sep):
+            path = path[1:]
 
-        path = self._filename.replace(self._root, '')
-        path = path.replace(os.path.basename(self._filename), '')
-        path = path[:-1]
-
-        absolute_path = self._filename.replace(self._datadir, '')
-        absolute_path = self._filename.replace(self._datadir, '', 1)
-        absolute_path = absolute_path.replace(file_basename, '')
-        absolute_path = absolute_path[1:][:-1]
-
-        if absolute_path and absolute_path[-1] == "/":
-            absolute_path = absolute_path[0:-1]
+        absolute_path = os.path.dirname(self._filename)
+        absolute_path = re.sub('^' + self._datadir + '/?', '', absolute_path)
 
         filenamenoext = os.path.splitext(file_basename)[0]
         if absolute_path == '':

Re: [Pyblosxom-devel] comments plugin fails when post is in datadir root

[Sebastian S. <Seb...@SS...>]

On 01/08/10 04:49, will wrote:
> I think I'll have to track down what absolute_path is supposed to be and
> what makes it different from other *path vars.

Here, in my wsgi setup, absolute_path is:

/path/to/my/datadir/category/category2/blogpost.txt
absolute_path: "category/category2"

/path/to/my/datadir/blogpost.txt
absolute_path: ""

That check for the existence of absolute_path is really not needed IMHO.

>> if entry['absolute_path'] and not entry.has_key("nocomments"):

But then, I have only been looking at pyblosxom since christmas.

spaetz

P.S. My test installation is here http://blog.sspaeth.de (mainly German)

Re: [Pyblosxom-devel] comments plugin fails when post is in datadir root

[will <wi...@bl...>]

I haven't gotten to looking at this problem (or other comments plugin 
problems) yet.

I think I'll have to track down what absolute_path is supposed to be and 
what makes it different from other *path vars.

I'll try to get to it soon.


On 01/05/2010 08:04 AM, Sebastian Spaeth wrote:
> I just reported
> https://sourceforge.net/tracker/?func=detail&aid=2926212&group_id=67445&atid=517918
> and the same issue was mentioned here:
> http://thread.gmane.org/gmane.comp.web.pyblosxom.devel/2166
>
> comments.py contains a check in cb_story() that abort comment reading
> when it fails:
>
> if entry['absolute_path'] and not entry.has_key("nocomments"):
>
> the thing is "absolute_path" is "" when a post is in the datadir root
> (ie in no category) and comments won't be read. This means the number of
> comments isn't displayed in the list view and there is no "post comment"
> link in the story-view.
>
> IMHO the absolute_path test is bogus and should simply be removed. I
> have done so locally and things work as expected now.
>
> -if entry['absolute_path'] and not entry.has_key("nocomments"):
> +if not entry.has_key("nocomments"):
>
> If more experienced devs agree, it would be good to make that change.
>
> spaetz
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>

Re: [Pyblosxom-devel] finishing up PyBlosxom 1.5

[will <wi...@bl...>]

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

Re: [Pyblosxom-devel] finishing up PyBlosxom 1.5

[chombee <ch...@la...>]

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.

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

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 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.

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?

I'm afraid I can't contribute as I'm writing my thesis, but at this
point (i.e. for 1.6) I think that sorting out the plugins (as Will
suggested) should be top priority. Plugins are very important for
Pyblosxom, you can only barely get a functional weblog out of Pyblosxom
without using any plugins, and yet with the current setup plugin rot is
a real problem. Perl blosxom uses the same plugin registry approach as
Pyblosxom does, with plugins self-hosted by their authors instead of
centrally hosted by the blosxom project. A few months ago I checked out
Perl blosxom again, and I found that so many of the download links to
plugins were broken that I couldn't even piece together a blog with some
very basic features. The same thing is already happening to Pyblosxom, a
lot of the download links in the plugin registry are broken or else link
to hopelessly out of date versions.

As I see it there are two serious problems we need to fix:

1. Plugin rot. Because plugins are hosted by their authors they
   eventually go offline, leaving broken links in the plugin registry,
   and these plugins are no longer available to new Pyblosxom users.
   
   Plugins may also be unmaintained and not work with the current
   version of Python or Pyblosxom.

2. Registry bottleneck. If you want to get a plugin added to the plugin
   registry or update a link you have to request the change from the
   small number of people who have the necessary access, and they
   (understandably) may not respond very quickly or at all.

The current system for Pyblosxom plugins is the worst of both worlds.
Plugins are hosted by their authors, and hence not kept together in a
central location that can be relied upon. And yet the plugin registry
(which is how users find plugins) is still centrally hosted, so
distributing the hosting of the plugins themsevles to the plugin authors
has created the plugin rot problem without solving the bottleneck
problem.

How do other projects handle plugins? One system I have seen, in Gnome
Do for example, is to have a set of "officialily supported plugins" plus
a set of "community plugins". The official plugins are a core set of
plugins that are maintained and centrally hosted as part of the
Pyblosxom project, maybe right there in the main svn branch or in a
separate repo like contrib for 1.3 used to be, and the official plugins
for a given version of Pyblosxom should work with that version of
Pyblosxom (if not, you have found a bug in the Pyblosxom project).

The community plugins are maintained by the plugin authors and not as an
official part of the project, so the Pyblosxom project itself makes no
guarantee that they will work.  I'm not sure if these should be hosted
centrally by the Pyblosxom project, just linked to from the Pyblosxom
site, or what. I want to avoid the registry bottleneck, but also avoid
the self-hosting rot. Maybe we could have a plugins wiki, forum or
mailing list, that plugins authors could post to when they have created
a new plugin or updated one? And then users could search this for a
plugin they want.

That Will wants to move the project off sourceforge may be important. Of
the potential new hosts for the project, what possibilities does each
provide for hosting "community supported" plugins?

Anyway, plugins certainly seem to me to be Pyblosxom's biggest issue,
the Pyblosxom code looks in pretty good shape, the plugin code looks
almost like that of blosxom: the ruins of a dead project.

On Sun, Jan 03, 2010 at 06:36:26PM -0500, will wrote:
> I spent today working on PyBlosxom 1.5.  Seriously.
> 
> I finished up the things in my todo list, I went through the bugs in the 
> bug tracker on SourceForge, and I spent time testing the command line 
> utility and going through the documentation.
> 
> Everything in svn trunk should be "good".  I pushed a lot of changes 
> today and I'm running the latest from trunk on my blog now.  I'm pretty 
> happy with where it is now.  The command line plugin interface is really 
> awesome and will make plugins more powerful.
> 
> Over the next week, I'm going to let the changes I've pushed bake in 
> svn.  I'll try to spend some time looking at plugins in contrib and 
> testing the popular ones.
> 
> After that, I want to get off of SourceForge.  I'd also like to switch 
> from svn to git or some other dvcs.  Having me as the bottleneck sucks 
> for everyone.  Gitorious looks interesting.  I'm also tempted to host it 
> on my own server.  I welcome thoughts on this (though we've talked about 
> this a few times over the last few years).
> 
> After that, I'll work on bug fixes and such and might start doing work 
> towards a PyBlosxom 1.6, though I'm not sure what that would entail, 
> yet.  I also want to work on the plugin situation because it sucks and 
> could be a lot better.
> 
> If you have some time and want to test out what's in svn, that'd be 
> really helpful.  Send issues, concerns, patches, and bugs to this list.
> 
> /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 
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

[Pyblosxom-devel] comments plugin fails when post is in datadir root

[Sebastian S. <Seb...@SS...>]

I just reported
https://sourceforge.net/tracker/?func=detail&aid=2926212&group_id=67445&atid=517918
and the same issue was mentioned here:
http://thread.gmane.org/gmane.comp.web.pyblosxom.devel/2166

comments.py contains a check in cb_story() that abort comment reading
when it fails:

if entry['absolute_path'] and not entry.has_key("nocomments"):

the thing is "absolute_path" is "" when a post is in the datadir root
(ie in no category) and comments won't be read. This means the number of
comments isn't displayed in the list view and there is no "post comment"
link in the story-view.

IMHO the absolute_path test is bogus and should simply be removed. I
have done so locally and things work as expected now.

-if entry['absolute_path'] and not entry.has_key("nocomments"):
+if not entry.has_key("nocomments"):

If more experienced devs agree, it would be good to make that change.

spaetz

Re: [Pyblosxom-devel] finishing up PyBlosxom 1.5

[Sebastian S. <Seb...@SS...>]

On 01/05/10 10:07, Sebastian Spaeth wrote:
> Having installed 1.5trunk now. It seems to run fine so far. I still get
> comment plugin trouble when submitting a comment with current trunk:
>
> File "/home/pyblosxom/plugins/comments.py", line 992, in cb_story_end
> comment_entry_base[key + '_escaped'] = entry[key + '_escaped']
> KeyError: 'bl_type_file_escaped'

Last mail on this topic, I promise. I commented out lines 992,993 and 
posting comments works flawlessly now.

So the problem seems to be that plugins/comments.py creates a 
"bl_type_file" key, but no _escaped and _urlencoded variants (which 
would actually be quite useless anyway). What is the best way to fix 
this properly?

spaetz