Re: [pyblosxom-users] packaging issues

Colin Walters wrote:

>I have created Debian packages, and they are currently waiting in the
>new package queue to be installed into the archive.  However, there are
>a few issues which if fixed would make my life easier as a packager.
>  
>
Wow, that's a great thing :) I'd love to be able to `apt-get install 
pyblosxom` :)

>One of the first I noticed was pyblosxom has a module named 'libs'. This
>is a pretty generic name.  I was originally going to put the pyblosxom
>libs/* files in /usr/lib/python2.2/site-packages/, but that would have
>intruded on the namespace too much, I think.  Could we rename 'libs' to
>'pyblosxom'?  That way other packages can more easily use the classes
>without having to futz with their sys.path.
>
Annoying ain't it? :(  That's for being extreme myopic, not knowing that 
pyblosxom would be used by more than, erm, me.. Actually for 0.8 (or 
planned future versions) the developers and I planned to make pyblosxom 
dist-utils friendly, so that you can have pyblosxom core installed in 
the system and users wishing to use it, would just need pyblosxom.cgi 
and config.py to get things working. You can then install pyblosxom in 
/usr/lib/python2.2/site-packages/PyBlosxom, or something like that. I've 
just got aquainted with dist-utils and have actually fallen in love with 
it :) Python makes it easy to do RPMs and Windows installers.

>Secondly, it would be cool if the default pyblosxom.cgi looked for an
>/etc/pyblosxom/config.py by default.
>
Problem is it involves doing python module import gymnastics.. But 
anyway, I'll let config.py be where pyblosxom.cgi (or whatever we wish 
to name it) is. The package should prbably include something like a 
config.py-dist.

>Now, the hairiest issue is plugins.  I'm not even sure where to put
>them.  Probably something like /usr/lib/pyblosxom/plugins.  
>
One of the things I want to do is to have user configurable plugin 
location. Then pyblosxom would really be installable site wide, and let 
users have their share of plugins. Then the rest of the plugins in 
contrib can be located at, say, /usr/share/pyblosxom/contrib, along with 
the license and readme files.

>Now, what I
>am thinking of is a setup like Apache2, which uses symlinks to
>enable/disable plugins (modules).  For example, we'd have:
>
>/usr/lib/pyblosxom/plugins-available/conditionalhttp.py
>And then to enable it, the user would do:
>cd /usr/lib/pyblosxom/plugins-enabled && ln -s ../plugins-available/conditionalhttp.py .
>
Plugins are already symlinkable.

>Or alternatively, a user would have to explicitly enable plugins in
>their config.py.  I like the former more though.
>
>One very minor issue; currently as far as I can tell there is no COPYING
>or LICENSE file included in the source.  The closest I could find was an
>__license__ = "Python".  It would be nice if the full text of the Python
>license was included in the pyblosxom distribution (and probably would
>be better from a legalistic standpoint too).
>  
>
I've been bugged by Will to about this :)

>Finally, I just want to say thanks for pyblosxom, it was an easy drop-in
>replacement for blosxom.
>
Tell you what, if I have more than five votes (you need three more:) of 
the major changes in pyblosxom, I'd do it and release Beta2 (or RC1?): 
Here's the things to do:

1. Rename libs to PyBlosxom (or something like that), along with the 
rename, this means changes to how everything import modules from libs/. 
The change is not as simple as just renaming the directories.
2. Update the previous docs that references libs/
3.  Kill off libs/plugins/__init__.py and rename it to 
PyBlosxom/plugins.py, plugins.py should be modified a bit to load 
plugins from a specified location, and the location should not ever need 
to have and __init__.py file at all (python module importing gymnastics 
made possible) I'll need Will's help for this a bit, so hope that he 
votes for it too.
4. Include some COPYING or LICENCE files (Could you include some example 
ones Colin?)
5. Create a nice dist-utils setup.py and setup.cfg files so that 
pyblosxom can be installed site-wide.

So developers (and users) do I have your votes? What this really mean 
for most of you is simplified installations of pyblosxom and plugins. 
Does really mean a bit more work for plugin developers (not really) and 
some work for pyblosxom developers, that of course will delay the 
release a bit (think of the new installation documentations).

And of course, this also means, install.exe's, RPMs and DEBs for users 
too afraid to touch setup.py.



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge