Re: License of the contrib plugins
Tollef Fog Heen <[email protected]>
| Newsgroups | gmane.comp.web.pyblosxom.devel |
|---|---|
| Organization | Private |
| Message-ID | <[email protected]> |
* will guaraldi
| On Mon, 4 Apr 2005, Tollef Fog Heen wrote:
| > | I don't think the contributed plugins are really in a state to be
| > | distributed by Debian given the mission you folks have. I think it's
| > | better to distribute the core (which should be fine) and then tell
| > | people to fetch the plugins they're looking for on their own.
| >
| > Ok. Since pyblosxom is a lot more useful with them, I think I'm going
| > to package them once we have them cleaned up.
|
| How exactly are you going to do that? Are you just going to include
| all the contributed plugins and users copy them from the /usr/share
| directory (or wherever they're getting placed) to their plugins
| directory?
Probably symlink, but yes, that's my initial idea. If the plugins are
then kept in sync with the core, you'll just upgrade both at the same
time and hopefully no breakage will occur.
| Are you planning on doing up a configuration script (I'm really not
| familiar with the internals of .deb stuff, but whatever gets kicked
| off with dpkg-reconfigure) for generating the config.py script and
| setting up the permissions?
The current packaging of pyblosxom assumes you only have one
installation and puts the config files in /etc. This makes sense on a
small box where you only have one user, but I suspect this isn't the
most common configuration (and even on my single-user box, I have a
copy of pyblosxom.cgi copied into my web directory and point that to a
config.py (which I've written by hand) my home directory. It then
uses the rest of pyblosxom, which lives in
/usr/lib/python2.4/site-packages/Pyblosxom . This isn't optimal and
breaks when the API changes. It'd be really nice if there was a way
you could have a pyblosxom.cgi which was more or less:
#! /usr/bin/python
import sys
sys.path.insert(0, "/home/tfheen/.pyblosxom")
sys.path.append('/usr/lib/python2.3/site-packages/pyblosxom/')
import config
if __name__ == '__main__':
from Pyblosxom.pyblosxom import DTRT
DTRT()
(where DTRT is shorthand for Do The Right Thing. :)
This would be stable across releases and even though plugins and such
might need adjustments, the need to ever edit pyblosxom.cgi would go away.
This could possibly be wrapped in a debconf-ed (debconf is the thing
that shows when you run dpkg-reconfigure) script which set up accounts
and made it really easy for people to initialise an installation.
| I'd be interested in any problems you come across with packaging. At
| a minimum, they'd be good things to think about as time goes on and we
| make changes towards user-friendliness.
If you have ideas on how it can be done better, I'm all ears.
Packaging web applications is very hard in as nobody has yet found a
great way of doing it. (You want it to work out of the box, but you
also want the admin to be able to customise and/or disable the
application, for a start.)
| I'll see what I can do in the next 5 days in terms of cleaning up the
| contributed plugins for Debian distribution. Then we'll see where we
| are at the end of the week and figure things out from there.
Excellent.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click