Merge lp:~madjar/wikkid/plugin into lp:wikkid

Proposed by Tim Penhey
Status: Merged
Merged at revision: 32
Proposed branch: lp:~madjar/wikkid/plugin
Merge into: lp:wikkid
Diff against target: 106 lines (+84/-0)
4 files modified
MANIFEST.in (+2/-0)
plugin/__init__.py (+3/-0)
plugin/commands.py (+49/-0)
setup.py (+30/-0)
To merge this branch: bzr merge lp:~madjar/wikkid/plugin
Reviewer Review Type Date Requested Status
Tim Penhey Approve
Georges Dubus (community) Approve
Barry Warsaw (community) Approve
Review via email: mp+25498@code.launchpad.net

Description of the change

Proposing for merging so I can see a clean diff.

To post a comment you must log in.
Revision history for this message
Tim Penhey (thumper) wrote :

I was planning on having a bzr plugin for wikkid, but I was initially planning on it being a separate code-base. What do you think the advantages are with this approach?

lp:~madjar/wikkid/plugin updated
28. By Tim Penhey

A slightly nicer directory listing.

Revision history for this message
Georges Dubus (madjar) wrote :

The main advantage of the plugin being included in the main codebase is that
anyone can get it with just a "bzr branch lp:wikkid" in the right place.

The main drawback is that it's base on what may be considered as a hack,
namely the "sys.path.append(os.path.dirname(__file__))" which tend not to work
perfectly in every situation (fails when called from ~/.bazaar/plugins, just
like loggerhead).

Separating the plugin and the main code makes it possible to write a much more
clean plugin, but would require the user to install wikkid before using the
plugin.

To sum up : the integrated plugin makes it easier to use, but may be kind of
hacky. Maybe we should seek advice from the loggerhead guys, who must have had
the same reflexion.

Revision history for this message
Paul Hummer (rockstar) wrote :

So, I think bundling it together is a good idea, but not the way loggerhead does it. I think it'd be better to have a separate package for the plugin, and use distutils/setuptools/distribute to handle putting the package in the right place on the python path.

In any case, I don't think __init__.py is a good place for this code.

Revision history for this message
Georges Dubus (madjar) wrote :

I agree with you. Anyway, wikkid as a plugin is not as important as it is for loggerhead. I'm not even sure that's really needed (it doesn't manipulate the branch,but rather uses it).

Keep up the work, wikkid will soon get very interesting. I'll try to help as much as I can, by testing and contributing if there's something I can do.

Revision history for this message
Tim Penhey (thumper) wrote :

Firstly, thanks Georges for your interest and eagerness.

I do really like the idea of having a plugin for wikkid.

I forsee something like:

$ cd some-dir
$ bzr branch lp:my-project/wiki my-project-wiki
$ cd my-project-wiki
$ bzr wikkid

Perhaps it even fires up a webbrowser pointing at the right port, and the user is free to edit the wiki offline.

I think it would be good to have it in the wikkid codebase somewhere, but I agree with Paul that having an __init__.py in the project root is a little icky.

Perhaps we put it somewhere like a plugin directory, and have a make target to add it to the ~/.bazaar/plugins directory. Although we'd still need to have to do something with the PYTHONPATH to get it working.

I'd like to be able to have a simple way to have the wikkid plugin point at my feature branch rather than my trunk branch (on packaged code one day) so I can still go 'bzr wikkid' (or bzr wiki) in my sandbox branch.

Ideas?

review: Needs Fixing
lp:~madjar/wikkid/plugin updated
29. By Tim Penhey

Add a new favicon.

30. By Tim Penhey

Change the style @import to a link.

Revision history for this message
Georges Dubus (madjar) wrote :

I've cleaned a little the __init__.py. Not that I want it to be merge, but
that was clearly breaking things.

The webbrowser thing is a great idea !

The plugin should not be installer in the ~, but rather in the system-wide
location for bazaar plugins : /usr/lib/python2.6/site-packages/bzrlib/plugins,
while wikkid go with the other python libs : /usr/lib/python2.6/site-packages.

Using a different wikkid codebase than the one installed would be as simple as
changing the PYTHONPATH, and to test another version of the plugin, you would
just have to put it in your ~/.bazaar/plugins

Revision history for this message
Georges Dubus (madjar) wrote :

I've added a setup.py script that will install or package wikkid using the distutils. You can call it using "python setup.py bdist" to get an idea of what will happen without doing it.

Is that what you where thinking about ?

If you're pleased, I'll refactor the plugin code in order to make something cleaner.

lp:~madjar/wikkid/plugin updated
31. By Tim Penhey

Fix the cancel link on the edit page, and some other minor refactoring.

Revision history for this message
Tim Penhey (thumper) wrote :

OK, I'm not familiar with distutils.

What is the Manifest file for?

Also if it is going to attempt to install the file 'run.py' into /usr/local/bin, we should rename it.

Do you see any point in distributing the test directories? Is it normal to do so?

I was certainly wanting a setup file at some stage. Would also want the pypi metadata too one day.

Revision history for this message
Georges Dubus (madjar) wrote :

> OK, I'm not familiar with distutils.
I wasn't until I read the documentation, so I may be wrong on some points

> What is the Manifest file for?
It's a list of the files that should be included in the source distribution (when running install.py sdist) and that are not already included as python modules.

> Also if it is going to attempt to install the file 'run.py' into
> /usr/local/bin, we should rename it.
Yes, obviously. Any suggestion for the name ? Would "wikkid" be good ?

> Do you see any point in distributing the test directories? Is it normal to do
> so?
running "find /usr/lib/python2.6/site-packages -name *test*" should convince you that's the usual thing to do. That's useful when, for example, the development version works, but stop working when you install it. The test will help you in that case. Also, the command "bzr selftest" tests the bazaar installation, including plugins.

> I was certainly wanting a setup file at some stage. Would also want the pypi
> metadata too one day.
If I've understood correctly the documentation, the windows installer should be available simply from the distutils, as well as the rpm packages. I believe debian has some facility to easily generate packages from it. pypi should be easy as well.

Revision history for this message
Tim Penhey (thumper) wrote :

On Thu, 20 May 2010 23:19:57 you wrote:
> > What is the Manifest file for?
>
> It's a list of the files that should be included in the source distribution
> (when running install.py sdist) and that are not already included as
> python modules.

OK, cool. Can we get a new line at the end of the file?

> > Also if it is going to attempt to install the file 'run.py' into
> > /usr/local/bin, we should rename it.
>
> Yes, obviously. Any suggestion for the name ? Would "wikkid" be good ?

Yes, I think that is a reasonable starting place.

> > Do you see any point in distributing the test directories? Is it normal
> > to do so?
>
> running "find /usr/lib/python2.6/site-packages -name *test*" should
> convince you that's the usual thing to do. That's useful when, for
> example, the development version works, but stop working when you install
> it. The test will help you in that case. Also, the command "bzr selftest"
> tests the bazaar installation, including plugins.

OK, fine.

> > I was certainly wanting a setup file at some stage. Would also want the
> > pypi metadata too one day.
>
> If I've understood correctly the documentation, the windows installer
> should be available simply from the distutils, as well as the rpm
> packages. I believe debian has some facility to easily generate packages
> from it. pypi should be easy as well.

I'm going to ask Barry to take a look at this as well. While Barry hasn't
been active in this project so far, he has expressed interest in the past, and
knows much more about distutils than I do, and may well be able to suggest a
change or two.

  reviewer barry

Also, this is 0.1 not 0.2 :-)

Will we still need the path hack in the plugin? I think not.

Thanks again

Tim

Revision history for this message
Georges Dubus (madjar) wrote :

> OK, cool. Can we get a new line at the end of the file?
Done
>

> > Yes, obviously. Any suggestion for the name ? Would "wikkid" be good ?
> Yes, I think that is a reasonable starting place.
I put wikkid.py, as wikkid would colide with the directory name wikkid. serve-wikkid could also be a good name

> I'm going to ask Barry to take a look at this as well. While Barry hasn't
> been active in this project so far, he has expressed interest in the past, and
> knows much more about distutils than I do, and may well be able to suggest a
> change or two.
Great, what I've done certainly needs to be reviewed.

> Also, this is 0.1 not 0.2 :-)
I didn't know what to put there, as the 0.1 was already out. Fixed.

> Will we still need the path hack in the plugin? I think not.
I'm going to rewrite a good part of the plugin.

review: Disapprove (not ready yet)
Revision history for this message
Barry Warsaw (barry) wrote :

Looks pretty reasonable. What I'd probably change in the setup.py though is to use some setuptools helpers instead of listing the packages explicitly. Also, you might want to include distribute_setup.py in the top level directory to get all the distribute goodness.

e.g.

from distribute_setup import use_setuptools
use_setuptools()
from setuptools import setup, find_packages

setup(
    ...
    packages=find_packages(),
    ...
    )

Distribute (comes on Ubuntu in python-setuptools) gives lots of nice benefits, such as running the test suite via 'python setup.py test', and automatic 2to3 running (once you're Python 3 or Python 2.6 -3 compatible).

Revision history for this message
Barry Warsaw (barry) wrote :

Oh, if cargo culting is your thing, you can look at the flufl.i18n package:

http://bazaar.launchpad.net/~barry/flufl.i18n/devel/files

:)

review: Approve
Revision history for this message
Georges Dubus (madjar) wrote :

I couldn't have it to understand the "bzrlib.plugins.wikkid" package correctly, using setuptools. Therefore, I'll keep it like it is.

Revision history for this message
Georges Dubus (madjar) :
review: Approve
Revision history for this message
Tim Penhey (thumper) wrote :

I'll merge it.

review: Approve
lp:~madjar/wikkid/plugin updated
32. By Tim Penhey

Merge in madjar's setup script branch and add some ignores.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file 'MANIFEST.in'
2--- MANIFEST.in 1970-01-01 00:00:00 +0000
3+++ MANIFEST.in 2010-05-21 09:25:42 +0000
4@@ -0,0 +1,2 @@
5+include INSTALL LICENCE README NEWS TODO Makefile MANIFEST.in
6+recursive-include wikkid/skin *
7
8=== added directory 'plugin'
9=== added file 'plugin/__init__.py'
10--- plugin/__init__.py 1970-01-01 00:00:00 +0000
11+++ plugin/__init__.py 2010-05-21 09:25:42 +0000
12@@ -0,0 +1,3 @@
13+from bzrlib.commands import plugin_cmds
14+
15+plugin_cmds.register_lazy('cmd_wikkid', 'wiki', 'bzrlib.plugins.wikkid.commands')
16
17=== added file 'plugin/commands.py'
18--- plugin/commands.py 1970-01-01 00:00:00 +0000
19+++ plugin/commands.py 2010-05-21 09:25:42 +0000
20@@ -0,0 +1,49 @@
21+import logging
22+import sys
23+
24+from bzrlib.commands import Command, register_command
25+from bzrlib.option import Option
26+
27+from bzrlib.workingtree import WorkingTree
28+
29+from wikkid.filestore.bzr import FileStore
30+from wikkid.model.factory import ResourceFactory
31+from wikkid.twistedserver import TwistedServer
32+from wikkid.user.bzr import UserFactory
33+
34+DEFAULT_PORT = 8080
35+
36+def setup_logging():
37+ """Set up a logger sending to stderr."""
38+ handler = logging.StreamHandler(strm=sys.stderr)
39+ fmt = '%(asctime)s %(levelname)-7s %(message)s'
40+ formatter = logging.Formatter(
41+ fmt=fmt, datefmt="%Y-%m-%d %H:%M:%S")
42+ handler.setFormatter(formatter)
43+ root = logging.getLogger()
44+ root.addHandler(handler)
45+
46+class cmd_wikkid(Command):
47+ """Serve branch as a wiki using wikkid."""
48+ aliases = ['wiki']
49+ takes_args = ['branch?']
50+ takes_options = [
51+ Option('port',
52+ help = 'Port to listen, defaults to 8080.',
53+ type = int,
54+ short_name = 'p')
55+ ]
56+
57+ def run(self, branch=u'.', port=8080):
58+ setup_logging()
59+ logger = logging.getLogger('wikkid')
60+ logger.setLevel(logging.DEBUG)
61+
62+ working_tree = WorkingTree.open(branch)
63+ logger.info('Using: %s', working_tree)
64+ filestore = FileStore(working_tree)
65+ server = TwistedServer(
66+ ResourceFactory(filestore),
67+ UserFactory(working_tree.branch),
68+ port=port)
69+ server.run()
70
71=== added file 'setup.py'
72--- setup.py 1970-01-01 00:00:00 +0000
73+++ setup.py 2010-05-21 09:25:42 +0000
74@@ -0,0 +1,30 @@
75+#!/usr/bin/env python
76+
77+from distutils.core import setup
78+
79+setup(name='Wikkid',
80+ version='0.1',
81+ description="A wiki that is backed by Bazaar that allows local branching of the wiki for later merging. Also doesn't have any page locks and uses Bazaar's three way merging.",
82+ author='Wikkid Committers',
83+ author_email='wikkid-dev@lists.launchpad.net',
84+ url='https://launchpad.net/wikkid',
85+ scripts=['wikkid-serve'],
86+ packages=['wikkid',
87+ 'wikkid/interface',
88+ 'wikkid/contrib',
89+ 'wikkid/contrib/creole_1_1',
90+ 'wikkid/model',
91+ 'wikkid/user',
92+ 'wikkid/tests',
93+ 'wikkid/tests/views',
94+ 'wikkid/tests/formatters',
95+ 'wikkid/view',
96+ 'wikkid/filestore',
97+ 'wikkid/skin',
98+ 'wikkid/formatter',
99+ 'bzrlib.plugins.wikkid'],
100+ package_dir={'bzrlib.plugins.wikkid':'plugin'},
101+ package_data={'wikkid/skin':['default/*.html',
102+ 'default/favicon.ico',
103+ 'default/static/*']},
104+ )
105
106=== renamed file 'run.py' => 'wikkid-serve'

Subscribers

People subscribed via source and target branches