pyblosxom-devel — Development Mailing List for pyblosxom

Re: [Pyblosxom-devel] let's talk about pyblosxom's future

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

First off, thank you Sebastian for all the work you've done on Pyblosxom!

Second, I'm excited about shameless plugs for two reasons:

1. if we have a list of them, then we can give that list to Pyblosxom 
users and it makes it easier to transfer to something else if they want 
to (they can just continue to use Pyblosxom ad infinitum if it works for 
them)

2. having a list makes it clearer whether there are Pyblosxom 
equivalents and makes it clearer whether it's good to end Pyblosxom now

volt looks really interesting. I think all the urls look the same except 
for permalink urls. So the only problem I'd have when switching is that 
I'd need to redirect existing blog entry permalinks to where they'd live 
under volt.

Sebastian: Did you solve that problem?

/will


On 06/08/2012 11:55 AM, seb...@ss... wrote:
>> Hi!
>>
>> I've taken a 6 month hiatus. Two things have happened in that time:
>>
>> 1. I picked up other projects.
>> 2. I didn't really miss working on pyblosxom.
>
> Hi Will,
>
> 1) it's sad to see pyblsoxom go
> 2) I can understand you quite well.
>
>
> I have toyed quite intensively with pyblsoxom for a while and while I like
> the coding style and it's workings, it's age shows. There are very nice
> templating engines out there, which make many things easier and it was not
> easy to make use of those engines without basically breaking all plugins
> and rewriting much...
>
>
> Shameless plug for a project that is not mine:
> I have to say that I defected from pyblosxom, and use "volt" now, which is
> a very you project using a nice templating engine, and is plugin based
> too.
>
> It takes plaintext, markdown, rst (or whatever you write a parser for),
> and creates static html pages using the jinja2 engine. It ncludes atom
> feed and monthly/yearly archives and tag-based index pages. It's extremly
> configurable and it was not too hard to convert my pyblosxom posts into
> the format that volt needed. I am not involved with the project, but it's
> a cool one. If you want to see volt output in action, have a look at my
> blog at http://sspaeth.de
>
> Sebastian

Re: [Pyblosxom-devel] let's talk about pyblosxom's future

[<seb...@ss...>]

> Hi!
>
> I've taken a 6 month hiatus. Two things have happened in that time:
>
> 1. I picked up other projects.
> 2. I didn't really miss working on pyblosxom.

Hi Will,

1) it's sad to see pyblsoxom go
2) I can understand you quite well.


I have toyed quite intensively with pyblsoxom for a while and while I like
the coding style and it's workings, it's age shows. There are very nice
templating engines out there, which make many things easier and it was not
easy to make use of those engines without basically breaking all plugins
and rewriting much...


Shameless plug for a project that is not mine:
I have to say that I defected from pyblosxom, and use "volt" now, which is
a very you project using a nice templating engine, and is plugin based
too.

It takes plaintext, markdown, rst (or whatever you write a parser for),
and creates static html pages using the jinja2 engine. It ncludes atom
feed and monthly/yearly archives and tag-based index pages. It's extremly
configurable and it was not too hard to convert my pyblosxom posts into
the format that volt needed. I am not involved with the project, but it's
a cool one. If you want to see volt output in action, have a look at my
blog at http://sspaeth.de

Sebastian

[Pyblosxom-devel] let's talk about pyblosxom's future

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

Hi!

I've taken a 6 month hiatus. Two things have happened in that time:

1. I picked up other projects.
2. I didn't really miss working on pyblosxom.

At this point, I think we should end the Pyblosxom project as it is and 
someone (probably not me) should start a new project that has the 
aspects of Pyblosxom that are interesting and ditch the enormous amount 
of technical debt and cruft that we've been hauling along for a decade now.

However, if Pyblosxom is really important to people and someone is 
interested in taking on maintenance of Pyblosxom, say so. I'm game for 
doing the work to transfer Pyblosxom off to one or more maintainers.

/will

[Pyblosxom-devel] Fwd: Pyblosxom plugin (breadcrumbs)

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

Florian: I'm forwarding this to the pyblosxom-devel mailing list because 
I don't have time to do anything with it. Thank you for sending this 
email, though. A breadcrumbs plugin sounds super!

Pyblosxom devs: If someone wants to add the plugin, the repository is 
the pyblosxom-web one on gitorious. Let me know when it's added and I 
can rebuild the site.

If someone wants to look into the pi_bl thing, it's probably prudent to 
figure out what the behavior should be, write some tests, apply the fix, 
and then we can go from there. It's possible the behavior is documented. 
I vaguely remember there are a few template variables that were 
sketchy--this might have been one of them.

Rock on!

/will


-------- Original Message --------
Subject: Pyblosxom plugin (breadcrumbs)
Date: Wed, 16 May 2012 21:35:52 +0200
From: Florian Bäuerle <flo...@go...>
To: wi...@bl...

Hi, my name is Florian Bäuerle.
I recently wrote a little Plugin for Pyblosxom that generates a
Breadcrumb-Path.
It is only written Quick & Dirty, but i will update it when I've got
enough time.
Name of Plugin: breadcrumbs
Category: navigation
Description: Generates a Breadcrumb-Navigation
Page about Plugin: http://fubar.ath.cx/weblog/Internet/Breadcrumbs%
20fuer%20Google%20und%20Co.html
Page to Download Plugin:
http://fubar.ath.cx/weblog/static/attachements/breadcrumbs.py

Additionally there is one little bug in pyblosxom that i fixed, and this
bug might affect the plugins output... the pi_bl looks different at
different pages of a pyblosxom-blog - sometimes with a slash at the
beginning, sometimes not. i fixed that by removing the first char of
that string on the corresponding place in the source

Kind Regards - and sorry for bad english (i'm tired)
Florian Bäuerle

Re: [Pyblosxom-devel] Patch for pagination in static-rendering mode

[Norman Y. <ya...@ya...>]

Another thing that might be considered, by the way, to make plugins for
changing the pagination style easier, would be to add another callback so
that the plugin author would not have to rewrite the whole of
truncatelist (or copy it).  Instead he'd be passed in the number of
subpages, all their URLs, and the page number of the current page.

On Fri, Mar 16, 2012 at 04:54:20PM -0400, Norman Yarvin wrote:
>Most of the code I added can easily be moved out to a plugin, since it
>falls under the cb_truncatelist callback which the existing 'paginate'
>plugin uses.  (That's why that plugin should still work.)
>
>The remainder of what I added is core infrastructure that would probably
>be necessary to support pagination under static rendering however it was
>done.  Without it, a plugin would have to find some way to add more files
>to the list of files to be rendered statically, when it found that an
>index page overflowed, and to do that in the middle of said rendering.
>(I didn't see a callback that would permit that, but perhaps there is
>one.)  Then some other piece of code would have to detect that the page
>to be rendered is a followup page, and render it accordingly.  It's
>simpler to just add a loop in the static-rendering code that iterates
>through the followup pages, passing down a variable which indicates 'now
>render followup page N', which is what I did.
>
>I considered moving the code that falls under cb_truncatelist out to the
>existing paginate plugin, but thought that the way I did it was better in
>line with the existing ethos of the program: provide basic functionality
>in the core, but let a plugin override it if they want to do something
>fancier.  The present behavior of just dropping entries off the ends of
>index pages unless the user installs a plugin seems unnecessarily
>unfriendly.
>
>The two decisions that the code I added bakes into the core are (1) the
>filenames for the followup pages under static rendering (I chose
>"filename_pageN.html") and (2) the fact that the way that pages are split
>up is by putting a fixed number of entries on each subpage, that number
>being given by the config variable num_entries.  Perhaps someone would
>want something different, with one of those, but they're not like the
>appearance of the navigation string in the output, where someone
>definitely will want something different (and which a plugin could
>change).
>
>So please reconsider adding it.
>
>On Fri, Mar 16, 2012 at 07:21:27AM -0400, will kahn-greene wrote:
>>I don't think it should be in the core. It's less an issue of "who 
>>would never use pagination" and more an issue of "are there different 
>>kinds of pagination behavior and thus should be supported in plugins". 
>>So I'm -1 on adding this to the core.
>>
>>I'll toss this and the patch into the issue tracker at some point and 
>>someone can look at absorbing the changes into the pagination plugin.
>>
>>/will
>>
>>
>>On Fri 16 Mar 2012 05:03:34 AM EDT, Norman Yarvin wrote:
>>> Attached is a patch that enables pagination in static-rendering mode,
>>> pagination being the rendering of index pages which are longer than
>>> num_entries by writing them out to multiple pages, combined with the
>>> production of navigation strings which the user can include in the
>>> templates for those pages.  Since:
>>>
>>> 	-- doing this as a plugin seemed somewhere between painful and
>>> 	impossible, and
>>>
>>> 	-- I think this really should be core functionality anyway,
>>>
>>> I went ahead and implemented the whole thing in the core.  It should work
>>> for dynamic rendering, too (or whatever one calls the opposite of static
>>> rendering), but I haven't tested that mode.  It is meant to supersede the
>>> present "paginate" plugin, but the latter should still work (again,
>>> untested).  It uses all the same config variables, except for
>>> "paginate_count_from", which I thought was far too much in the
>>> bikeshedding direction to be worth saving.  The variable
>>> "paginate_linkstyle" accepts, besides the old settings (0 or 1), the more
>>> descriptive settings "1 of 4" (same as style 1) or "1234" (same as style 0).
>>>
>>> For static rendering, instead of the page number being sent in the HTML
>>> query, as in
>>>
>>> 	http://example.com/blog/index.html?page=2
>>>
>>> it has to be part of the filename, as in
>>>
>>> 	http://example.com/blog/index_page2.html
>>>
>>> which is now this change does it.
>>>
>>> I haven't yet fixed up the documentation to reflect the changes.
>>>
>>> (As for why I think this should be core functionality, I can't imagine
>>> anyone not wanting it, at least for normal weblog use.)
>>>
>>>
>>>
>>>
>>>
>>> This body part will be downloaded on demand.
>>>
>>>
>>> This body part will be downloaded on demand.
>
>------------------------------------------------------------------------------
>This SF email is sponsosred by:
>Try Windows Azure free for 90 days Click Here 
>http://p.sf.net/sfu/sfd2d-msazure
>_______________________________________________
>Pyblosxom-devel mailing list
>Pyb...@li...
>https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] Patch for pagination in static-rendering mode

[Norman Y. <ya...@ya...>]

Most of the code I added can easily be moved out to a plugin, since it
falls under the cb_truncatelist callback which the existing 'paginate'
plugin uses.  (That's why that plugin should still work.)

The remainder of what I added is core infrastructure that would probably
be necessary to support pagination under static rendering however it was
done.  Without it, a plugin would have to find some way to add more files
to the list of files to be rendered statically, when it found that an
index page overflowed, and to do that in the middle of said rendering.
(I didn't see a callback that would permit that, but perhaps there is
one.)  Then some other piece of code would have to detect that the page
to be rendered is a followup page, and render it accordingly.  It's
simpler to just add a loop in the static-rendering code that iterates
through the followup pages, passing down a variable which indicates 'now
render followup page N', which is what I did.

I considered moving the code that falls under cb_truncatelist out to the
existing paginate plugin, but thought that the way I did it was better in
line with the existing ethos of the program: provide basic functionality
in the core, but let a plugin override it if they want to do something
fancier.  The present behavior of just dropping entries off the ends of
index pages unless the user installs a plugin seems unnecessarily
unfriendly.

The two decisions that the code I added bakes into the core are (1) the
filenames for the followup pages under static rendering (I chose
"filename_pageN.html") and (2) the fact that the way that pages are split
up is by putting a fixed number of entries on each subpage, that number
being given by the config variable num_entries.  Perhaps someone would
want something different, with one of those, but they're not like the
appearance of the navigation string in the output, where someone
definitely will want something different (and which a plugin could
change).

So please reconsider adding it.

On Fri, Mar 16, 2012 at 07:21:27AM -0400, will kahn-greene wrote:
>I don't think it should be in the core. It's less an issue of "who 
>would never use pagination" and more an issue of "are there different 
>kinds of pagination behavior and thus should be supported in plugins". 
>So I'm -1 on adding this to the core.
>
>I'll toss this and the patch into the issue tracker at some point and 
>someone can look at absorbing the changes into the pagination plugin.
>
>/will
>
>
>On Fri 16 Mar 2012 05:03:34 AM EDT, Norman Yarvin wrote:
>> Attached is a patch that enables pagination in static-rendering mode,
>> pagination being the rendering of index pages which are longer than
>> num_entries by writing them out to multiple pages, combined with the
>> production of navigation strings which the user can include in the
>> templates for those pages.  Since:
>>
>> 	-- doing this as a plugin seemed somewhere between painful and
>> 	impossible, and
>>
>> 	-- I think this really should be core functionality anyway,
>>
>> I went ahead and implemented the whole thing in the core.  It should work
>> for dynamic rendering, too (or whatever one calls the opposite of static
>> rendering), but I haven't tested that mode.  It is meant to supersede the
>> present "paginate" plugin, but the latter should still work (again,
>> untested).  It uses all the same config variables, except for
>> "paginate_count_from", which I thought was far too much in the
>> bikeshedding direction to be worth saving.  The variable
>> "paginate_linkstyle" accepts, besides the old settings (0 or 1), the more
>> descriptive settings "1 of 4" (same as style 1) or "1234" (same as style 0).
>>
>> For static rendering, instead of the page number being sent in the HTML
>> query, as in
>>
>> 	http://example.com/blog/index.html?page=2
>>
>> it has to be part of the filename, as in
>>
>> 	http://example.com/blog/index_page2.html
>>
>> which is now this change does it.
>>
>> I haven't yet fixed up the documentation to reflect the changes.
>>
>> (As for why I think this should be core functionality, I can't imagine
>> anyone not wanting it, at least for normal weblog use.)
>>
>>
>>
>>
>>
>> This body part will be downloaded on demand.
>>
>>
>> This body part will be downloaded on demand.

Re: [Pyblosxom-devel] Patch for pagination in static-rendering mode

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

I don't think it should be in the core. It's less an issue of "who 
would never use pagination" and more an issue of "are there different 
kinds of pagination behavior and thus should be supported in plugins". 
So I'm -1 on adding this to the core.

I'll toss this and the patch into the issue tracker at some point and 
someone can look at absorbing the changes into the pagination plugin.

/will


On Fri 16 Mar 2012 05:03:34 AM EDT, Norman Yarvin wrote:
> Attached is a patch that enables pagination in static-rendering mode,
> pagination being the rendering of index pages which are longer than
> num_entries by writing them out to multiple pages, combined with the
> production of navigation strings which the user can include in the
> templates for those pages.  Since:
>
> 	-- doing this as a plugin seemed somewhere between painful and
> 	impossible, and
>
> 	-- I think this really should be core functionality anyway,
>
> I went ahead and implemented the whole thing in the core.  It should work
> for dynamic rendering, too (or whatever one calls the opposite of static
> rendering), but I haven't tested that mode.  It is meant to supersede the
> present "paginate" plugin, but the latter should still work (again,
> untested).  It uses all the same config variables, except for
> "paginate_count_from", which I thought was far too much in the
> bikeshedding direction to be worth saving.  The variable
> "paginate_linkstyle" accepts, besides the old settings (0 or 1), the more
> descriptive settings "1 of 4" (same as style 1) or "1234" (same as style 0).
>
> For static rendering, instead of the page number being sent in the HTML
> query, as in
>
> 	http://example.com/blog/index.html?page=2
>
> it has to be part of the filename, as in
>
> 	http://example.com/blog/index_page2.html
>
> which is now this change does it.
>
> I haven't yet fixed up the documentation to reflect the changes.
>
> (As for why I think this should be core functionality, I can't imagine
> anyone not wanting it, at least for normal weblog use.)
>
>
>
>
>
> This body part will be downloaded on demand.
>
>
> This body part will be downloaded on demand.

[Pyblosxom-devel] Patch for pagination in static-rendering mode

[Norman Y. <ya...@ya...>]

Attached is a patch that enables pagination in static-rendering mode,
pagination being the rendering of index pages which are longer than
num_entries by writing them out to multiple pages, combined with the
production of navigation strings which the user can include in the
templates for those pages.  Since:

	-- doing this as a plugin seemed somewhere between painful and
	impossible, and

	-- I think this really should be core functionality anyway,

I went ahead and implemented the whole thing in the core.  It should work
for dynamic rendering, too (or whatever one calls the opposite of static
rendering), but I haven't tested that mode.  It is meant to supersede the
present "paginate" plugin, but the latter should still work (again,
untested).  It uses all the same config variables, except for
"paginate_count_from", which I thought was far too much in the
bikeshedding direction to be worth saving.  The variable
"paginate_linkstyle" accepts, besides the old settings (0 or 1), the more
descriptive settings "1 of 4" (same as style 1) or "1234" (same as style 0).

For static rendering, instead of the page number being sent in the HTML
query, as in

	http://example.com/blog/index.html?page=2

it has to be part of the filename, as in

	http://example.com/blog/index_page2.html

which is now this change does it.

I haven't yet fixed up the documentation to reflect the changes.

(As for why I think this should be core functionality, I can't imagine
anyone not wanting it, at least for normal weblog use.)



-- 
Norman Yarvin					http://yarchive.net/blog

Re: [Pyblosxom-devel] 1.5 status -- anything more to do?

[Will Kahn-G. <wi...@bl...>]

Anything is fine by me.  Patches sent to the mailing list, pull requests 
on github, issues on github with comments on how to fix the issue, pinging 
me on IRC, ...


On Sat, 17 Dec 2011, Akai wrote:
> 
> What would be the best way to contribute post-hiatus?
>
> On 12/17/2011 5:17 PM, Will Kahn-Greene wrote:
>> I worked through the remaining bugs sitting in the 1.5 milestone today.
>> Now there are no more bugs sitting in the 1.5 milestone.
>> 
>> If there's anything outstanding that I haven't finished up, let me know in
>> the next two days.  Barring any issues, I'm going to ship 1.5 next week.
>> 
>> After 1.5 goes out, I'm going to spend some time moving interesting bugs
>> to the issue tracker on github and then take a hiatus from Pyblosxom
>> development for a while.  I will continue to work through patches
>> submitted by other people whether they code or docs or fixes to the
>> website.
>> 
>> /will
>>
>> 
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at http://p.sf.net/sfu/ms-windowsazure
>> _______________________________________________
>> Pyblosxom-devel mailing list
>> Pyb...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>

[Pyblosxom-devel] 1.5 status -- anything more to do?

[Will Kahn-G. <wi...@bl...>]

I worked through the remaining bugs sitting in the 1.5 milestone today. 
Now there are no more bugs sitting in the 1.5 milestone.

If there's anything outstanding that I haven't finished up, let me know in 
the next two days.  Barring any issues, I'm going to ship 1.5 next week.

After 1.5 goes out, I'm going to spend some time moving interesting bugs 
to the issue tracker on github and then take a hiatus from Pyblosxom 
development for a while.  I will continue to work through patches 
submitted by other people whether they code or docs or fixes to the 
website.

/will

Re: [Pyblosxom-devel] project infrastructure

[<Seb...@ss...>]

I know both well... :-) what I implied is that the git repo is essentially the same. I hardly ever view the web ui of my githhub projects, and you can always mix with better infrastructure, ie bug trackers from assembla.com or whatnot.
That having said, github is certainly cool.
Sebastian


>> github or gitorious? ppff,
>> it's just a different git@ URL ;-)
>> 
>
>I know you meant that as a joke, but seriously, github and gitorious
>are quite different.
>personally i find gitorious very hard to navigate, their UI/menus
>aren't very well thought out.

Re: [Pyblosxom-devel] project infrastructure

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

On Fri 02 Dec 2011 01:37:08 PM EST, Dieter Plaetinck wrote:
> On Fri, 02 Dec 2011 13:23:03 -0500
> will kahn-greene <wi...@bl...> wrote:
>
>> Given that, switching to the github issue tracker is fine
>> and doesn't lock us in.
>
> GH issues doesn't lock us in? is that a typo or am i missing something?

You removed the context for that statement in your reply.  It doesn't 
lock us in because I don't really care about leaving issues if we 
switch trackers.


>> I don't want to use Trac, Roundup
>
> what's wrong with roundup?

Pretty sure I've talked about this already, but I'm game for iterating 
through it again.

Roundup doesn't have milestones by default.  I've added mediocre 
milestone stuff based on the original round of milestone stuff that 
Jack at OpenHatch did.  However, the urls for milestones are awful and 
generally I find the ui to be problematic.  There are bugs in Roundup 
that irritate me.  One of them is that the ExportCSV action doesn't 
check the querystring _before_ writing stuff to output.  So when it 
hits a problem, it's already written stuff to output and thus you get 
back an HTTP 200 response with gibberish in it.  The problem there is 
that Google bot and other search engines for some reason put bad stuff 
in the querystring and thus I get a ton of error emails.  I tried to 
fix this in Roundup and write up a test case, but the Roundup code is 
really funky and totally alien to me and after spending a bunch of time 
on it, I just gave up.  On top of that, I think the ui is clunky and it 
took me a day or two to figure out how to set it up.  Ipso facto, I 
find Roundup more complex than I can wrap my head around, doesn't have 
features I want out of the box, and has bugs that affect me.

/will

Re: [Pyblosxom-devel] project infrastructure

[Dieter P. <di...@pl...>]

On Fri, 02 Dec 2011 13:23:03 -0500
will kahn-greene <wi...@bl...> wrote:

> Given that, switching to the github issue tracker is fine
> and doesn't lock us in.

GH issues doesn't lock us in? is that a typo or am i missing something?

> I don't want to use Trac, Roundup

what's wrong with roundup?

Re: [Pyblosxom-devel] project infrastructure

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

On Fri 02 Dec 2011 01:05:57 PM EST, seanh wrote:
>> 1. Move from gitorious to github.  In doing this, we gain post-commit 
>> hooks some of which are wildly useful, an issue tracker, inline comments 
>> for pull requests, probably an order of magnitude more people who already 
>> have github accounts and who are used to drive-by-fixes, and probably some 
>> other github features I haven't yet discovered.
>
> Github can host the project website for you as well, and a wiki.
>
> The one disadvantage is that it's not open source whereas gitorious is.
> Hosting your git repo on github doesn't tie you down to anything as you
> can always move it somewhere else if you want to. But the more you come
> to depend on github's extra features like the issue tracker, the wiki,
> etc., the more you're becoming dependent on a proprietary platform.

I dig what you're saying.  I definitely don't want to repeat another SF 
situation--that sucked.

I currently plan to use github for code, the issue tracker, and patch 
workflow.  We can trivially move the code elsewhere.  The patch 
workflow is transient, so if we move elsewhere we'll lose that and 
change workflows.

That brings us to the issue tracker.  I'm pretty ok with ditching 
issues in one system and moving to a new system.  More often than not, 
issues that languish are either fixed, uninteresting, not fleshed out 
or in some state where ditching it isn't a big deal.  I don't want this 
project to accrue task-debt.  We either work on things we're interested 
in, or we don't.  The set of issues we're interested in working on 
changes.  If I had my druthers, I'd have our bug system auto-expire 
bugs that haven't been touched in a couple of months.  Given that, 
switching to the github issue tracker is fine and doesn't lock us in.  
I'm game for hosting our own bug tracker, but I don't want to use Trac, 
Roundup or a non-Python-based tracker.  That really limits the options. 
 Essentially it means I should write my own bug tracker that meets my 
needs.  I may do that at some point, but not any time soon.

The website (currently at http://pyblosxom.bluesock.org/) will stay 
where it is and act as an anchor for the project allowing us to switch 
infrastructure without losing people.

That's what I'm currently thinking.

/will

Re: [Pyblosxom-devel] project infrastructure

[seanh <sn...@gm...>]

> 1. Move from gitorious to github.  In doing this, we gain post-commit 
> hooks some of which are wildly useful, an issue tracker, inline comments 
> for pull requests, probably an order of magnitude more people who already 
> have github accounts and who are used to drive-by-fixes, and probably some 
> other github features I haven't yet discovered.

Github can host the project website for you as well, and a wiki.

The one disadvantage is that it's not open source whereas gitorious is.
Hosting your git repo on github doesn't tie you down to anything as you
can always move it somewhere else if you want to. But the more you come
to depend on github's extra features like the issue tracker, the wiki,
etc., the more you're becoming dependent on a proprietary platform.

Re: [Pyblosxom-devel] project infrastructure

[Dieter P. <di...@pl...>]

On Thu, 01 Dec 2011 16:25:18 +0100
Sebastian Spaeth <Seb...@SS...> wrote:

> github or gitorious? ppff,
> it's just a different git@ URL ;-)
> 

I know you meant that as a joke, but seriously, github and gitorious are quite different.
personally i find gitorious very hard to navigate, their UI/menus aren't very well thought out.

Re: [Pyblosxom-devel] project infrastructure

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

On Wed, 23 Nov 2011 19:20:23 -0500 (EST), Will Kahn-Greene wrote:

A bit lateish, but I have no strong opinions on gitorious vs github (I
think keeping the repo at gitorious would be fine). But I am always for
hosting things at existing infrastructure, relieving you from the burden
of maintaining that. So using some bug tracker at github, assembla or
whereever, sounds good to me. github or gitorious? ppff, it's just a
different git@ URL ;-)

Sebastian

Re: [Pyblosxom-devel] project infrastructure

[<war...@gm...>]

On 24 November 2011 AM 9:00:04 Dieter Plaetinck wrote:
> personally I find it a pain to navigate in gitorious.  I have the impression
> that what I'm looking for is usually not where I expect to find it.

Heh.. That was my first time trying to look for pyblosxom in Gitorious. Then 
again, was very new to this 'git' thing, and forks, and clones, etc. But quite 
at home with our install at the office.

So github it is? +1 on that for me.

Re: [Pyblosxom-devel] project infrastructure

[Dieter P. <di...@pl...>]

On Thu, 24 Nov 2011 10:30:05 +0800
"Wari Wahab" <wa...@ho...> wrote:

> And the community around it, it makes Gitorious like a quiet boy
> sitting in the corner. I have no idea why Github is so popular.

because it's a really good application, integrates well, is free and the people who run it
are capable and very active in open source communities (ruby, git and more)

personally I find it a pain to navigate in gitorious.  I have the impression that what I'm looking for
is usually not where I expect to find it.

The last time this came up I was pro github, and I still am :)


Dieter



> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] project infrastructure

[Wari W. <wa...@ho...>]

<quote who="Will Kahn-Greene">
> 1. Move from gitorious to github.
> 2. Move the Pyblosxom manual to ReadTheDocs.
> 3. Ditch roundup and use the github issue tracker.
> Any thoughts on this?  Is anyone against it?  If not, I'm going to do this
> before releasing 1.5 since I want to update the urls everywhere.

Wow, hey, I'm totally not against this. I use Gitorious on our private
install
in our company and it's a great product for that. Since we have Redmine as
our
bugtracker/documentation store, these two worked somewhat seemlessly and has
been something that the company is accustomed to.

Moving to Github is definitely a plus as you gain the all-in-one
featureset of
a bug tracker, repository, etc. And to top it all up, I love the edit-in-
place-auto-fork-and-merge-request in less than a minute of kung-fu moves
feature, etc.

And the community around it, it makes Gitorious like a quiet boy sitting in
the corner. I have no idea why Github is so popular.

Re: [Pyblosxom-devel] project infrastructure

[Tim G. <tg...@pr...>]

On Nov 23, 2011 at 07:20 PM -0500, Will Kahn-Greene wrote:
>Any thoughts on this?  Is anyone against it?  If not, I'm going to do this
>before releasing 1.5 since I want to update the urls everywhere.
>Hopefully before the end of this year.

Makes sense to me.  Github is nice.

[Pyblosxom-devel] project infrastructure

[Will Kahn-G. <wi...@bl...>]

I updated the roundup package on bluesock (the server that hosts the 
Pyblosxom bug tracker) and inadvertently stomped on the fix I made to 
roundup.  Then I started getting lots of error emails from roundup because 
it's "helpful".  Took me about 30 minutes to figure out how I fixed it the 
last time and re-fix it.  Irritating.

That got me thinking.  A while back, when we talked about switching to git 
and picking a host, I remember a lot of people said they already had 
github accounts.  I picked gitorious because at the time is was close 
enough feature-wise and it was Free Software.  I picked roundup because it 
seemed like a decent choice.

At this point, I want to revisit those decisions.  I'm thinking of moving 
things around in this way:

1. Move from gitorious to github.  In doing this, we gain post-commit 
hooks some of which are wildly useful, an issue tracker, inline comments 
for pull requests, probably an order of magnitude more people who already 
have github accounts and who are used to drive-by-fixes, and probably some 
other github features I haven't yet discovered.

2. Move the Pyblosxom manual to ReadTheDocs.  We're already using Sphinx. 
If we switch to github, then it's a post-commit hook to update it 
everytime something gets checked in.  This would be really nice.

3. Ditch roundup and use the github issue tracker.

After that we can see where things are at.

Any thoughts on this?  Is anyone against it?  If not, I'm going to do this 
before releasing 1.5 since I want to update the urls everywhere. 
Hopefully before the end of this year.

/will

Re: [Pyblosxom-devel] Installing plugins

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

I can't remember if I mentioned it or not, yet, but this is one of the
other things I changed last week: all core plugins have documentation in
the Pyblosxom manual now.  It's all in "part 2" of the manual:

http://pyblosxom.bluesock.org/1.5/index.html#part-2-core-plugin-documentation

The documentation is extracted from the docstring at the top of the file
with a script.  In this way, we can update the plugins and the
documentation for the plugins all at once and then it gets pulled into
the manual automatically.

This also solves the problem of "Where's the damn docs for this plugin I
enabled with 'Pyblosxom.plugins.xyz'?"

Also, I did some minor renaming:

* rst -> rst_parser
* markdown -> markdown_parser

Changes are covered in the updated WHATSNEW section for 1.5rc4 (which
might end up being 1.5final--we'll see):

http://pyblosxom.bluesock.org/1.5/whatsnew.html#what-s-new-in-1-5-rc4-in-development

/will


On 11/09/2011 07:26 AM, will kahn-greene wrote:
> The comments plugin requires more setup than just adding it to the 
> load_plugins list.  There's documentation here:
> 
> http://pyblosxom.bluesock.org/1.5/plugins/comments.html
> 
> Hope that helps!
> 
> /will
> 
> 
> On Tue 08 Nov 2011 08:18:56 PM EST, Akai wrote:
>> Mostly tried to see if there was any change. I can't figure out how to
>> get comments on my blog and I assumed that adding a comments plugin
>> would do something
>>
>>
>>
>> On 11/9/2011 3:14 AM, Will Kahn-Greene wrote:
>>>
>>> There really isn't a "new" method.  The only thing that changed last
>>> week is that a bunch of plugins are now in the Pyblosxom.plugins
>>> package. Because of that, they're already on sys.path and you can just
>>> refer to them as "Pyblosxom.plugins.xyz" without specifying additional
>>> directories in your plugin_dirs.
>>>
>>> Thus, to use comments with what's in git master, you can do:
>>>
>>> py["plugin_dirs"] = []
>>> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
>>>
>>>
>>> The things you've done in your plugin_dirs in this case won't help,
>>> but probably won't hinder you either.
>>>
>>> Why do you think this isn't loading plugins?  What did you do to see
>>> if the plugins were being loaded or not?
>>>
>>> /will
>>>
>>>
>>> On Wed, 9 Nov 2011, Akai wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Sorry to be bugging you guys..
>>>> I can't manage to install any plugins
>>>> I tried the "new" method from the WHATSNEW file and the old ones from
>>>> the other docs
>>>> some of my attempts:
>>>>
>>>> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
>>>> py["plugin_dirs"] = [os.path.join(blogdir,
>>>> "plugins"),"/home/sites/bloxblog/Pyblosxom/plugins"]
>>>> etc..
>>>>
>>>> I'm running the current GIT head version if that helps, using CGI
>>>> rendering (though I tried Paste as well)
>>>>
>>>> -Akai
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> RSA(R) Conference 2012
>>>> Save $700 by Nov 18
>>>> Register now
>>>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>>> _______________________________________________
>>>> Pyblosxom-devel mailing list
>>>> Pyb...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>>>>

Re: [Pyblosxom-devel] Installing plugins

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

The comments plugin requires more setup than just adding it to the 
load_plugins list.  There's documentation here:

http://pyblosxom.bluesock.org/1.5/plugins/comments.html

Hope that helps!

/will


On Tue 08 Nov 2011 08:18:56 PM EST, Akai wrote:
> Mostly tried to see if there was any change. I can't figure out how to
> get comments on my blog and I assumed that adding a comments plugin
> would do something
>
>
>
> On 11/9/2011 3:14 AM, Will Kahn-Greene wrote:
>>
>> There really isn't a "new" method.  The only thing that changed last
>> week is that a bunch of plugins are now in the Pyblosxom.plugins
>> package. Because of that, they're already on sys.path and you can just
>> refer to them as "Pyblosxom.plugins.xyz" without specifying additional
>> directories in your plugin_dirs.
>>
>> Thus, to use comments with what's in git master, you can do:
>>
>> py["plugin_dirs"] = []
>> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
>>
>>
>> The things you've done in your plugin_dirs in this case won't help,
>> but probably won't hinder you either.
>>
>> Why do you think this isn't loading plugins?  What did you do to see
>> if the plugins were being loaded or not?
>>
>> /will
>>
>>
>> On Wed, 9 Nov 2011, Akai wrote:
>>>
>>> Hi everyone,
>>>
>>> Sorry to be bugging you guys..
>>> I can't manage to install any plugins
>>> I tried the "new" method from the WHATSNEW file and the old ones from
>>> the other docs
>>> some of my attempts:
>>>
>>> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
>>> py["plugin_dirs"] = [os.path.join(blogdir,
>>> "plugins"),"/home/sites/bloxblog/Pyblosxom/plugins"]
>>> etc..
>>>
>>> I'm running the current GIT head version if that helps, using CGI
>>> rendering (though I tried Paste as well)
>>>
>>> -Akai
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> RSA(R) Conference 2012
>>> Save $700 by Nov 18
>>> Register now
>>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>> _______________________________________________
>>> Pyblosxom-devel mailing list
>>> Pyb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>>>

Re: [Pyblosxom-devel] Installing plugins

[Akai <ope...@gm...>]

Mostly tried to see if there was any change. I can't figure out how to
get comments on my blog and I assumed that adding a comments plugin
would do something



On 11/9/2011 3:14 AM, Will Kahn-Greene wrote:
>
> There really isn't a "new" method.  The only thing that changed last
> week is that a bunch of plugins are now in the Pyblosxom.plugins
> package. Because of that, they're already on sys.path and you can just
> refer to them as "Pyblosxom.plugins.xyz" without specifying additional
> directories in your plugin_dirs.
>
> Thus, to use comments with what's in git master, you can do:
>
> py["plugin_dirs"] = []
> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
>
>
> The things you've done in your plugin_dirs in this case won't help,
> but probably won't hinder you either.
>
> Why do you think this isn't loading plugins?  What did you do to see
> if the plugins were being loaded or not?
>
> /will
>
>
> On Wed, 9 Nov 2011, Akai wrote:
>>
>> Hi everyone,
>>
>> Sorry to be bugging you guys..
>> I can't manage to install any plugins
>> I tried the "new" method from the WHATSNEW file and the old ones from
>> the other docs
>> some of my attempts:
>>
>> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
>> py["plugin_dirs"] = [os.path.join(blogdir,
>> "plugins"),"/home/sites/bloxblog/Pyblosxom/plugins"]
>> etc..
>>
>> I'm running the current GIT head version if that helps, using CGI
>> rendering (though I tried Paste as well)
>>
>> -Akai
>>
>> ------------------------------------------------------------------------------
>>
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Pyblosxom-devel mailing list
>> Pyb...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>>