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 | ||||
Related bugs: |
|
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 |
Commit message
Description of the change
Proposing for merging so I can see a clean diff.
Tim Penhey (thumper) wrote : | # |
- 28. By Tim Penhey
-
A slightly nicer directory listing.
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.
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.
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/
In any case, I don't think __init__.py is a good place for this code.
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.
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?
- 29. By Tim Penhey
-
Add a new favicon.
- 30. By Tim Penhey
-
Change the style @import to a link.
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/
while wikkid go with the other python libs : /usr/lib/
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
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.
- 31. By Tim Penhey
-
Fix the cancel link on the edit page, and some other minor refactoring.
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.
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/
> 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.
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/
> 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
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.
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=
...
)
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).
Barry Warsaw (barry) wrote : | # |
Oh, if cargo culting is your thing, you can look at the flufl.i18n package:
http://
:)
Georges Dubus (madjar) wrote : | # |
I couldn't have it to understand the "bzrlib.
Georges Dubus (madjar) : | # |
- 32. By Tim Penhey
-
Merge in madjar's setup script branch and add some ignores.
Preview Diff
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' |
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?