So I finally got around to setting up a script that rsyncsupdates my Bazaar-NG branches nightly via SFTP. (I would have just done a cron script that does bzr pull sftp://[...], but the ssh binary on the webserver is freakishly old and not openssh)(It was a problem with using rbash instead of using rssh as the restricted shell) I also have a human-readable version, courtesy of bzr's webserve plugin. There you will find the links to the respective repositories. If the link doesn't work, try installing pycurl, as it seems that the non-pycurl code doesn't handle 302 redirects very well. One of these days I'll (try) to get trac installed (because I dislike webserve's interface, and bug reporting capabilities are also a plus), but that means I have to run it via CGI. Stupid admins not enabling FastCGI even though it's installed and even says so in the server signature.
Of particular note is the TracAtomPP branch, which as one can (maybe) guess, adds support for the Atom Publishing Protocol to Trac. This is something that I've been working on lately, in order to give myself a break from xmingw porting. So far, I've got a good chunk of the base done, and I'm currently working on the wiki "collection" module.
On the subject of xmingw, if anyone could test out the xmingw branch with layman, it would be appreciated (because I would like to know if its bzr support works yet).
Posts
10 comments:
This is very interesting.
I'm not entirely sure how the requests are getting to the plugin though - where is the endpoint URL specified?
Given that I tend to code rather abstractly, I can understand why you can't seem to find the endpoint URL. Currently (i.e., the committed code as of this comment), the endpoint (to the introspection document, I assume you mean) is <http://example.com/path/to/trac/atom>. In a future commit (in order to get authentication working correctly without ugly hacks), the endpoint will be <http://example.com/path/to/trac/login/atom>.
(BTW, I am rather annoyed by the number of HTML tags that I can't use in comments...)
OK, that's what I'd thought, but both a browser request and a wget to http://example.com/path/to/trac/atom gives me a 404 (which is why I thought I had it wrong).
I thought there might have been a permissions issue (with "assert_has_permissions") but I think I've granted this correctly and it still doesn't work. A quick change to return 200 and some text if the permissions check fails, but no dice.
At this point, my Trac and Python module knowledge has been pushed to its limit, so I may have to bow out gracefully :)
slightly OT: This is the first time I've actually used an egg - is there a standard way of developing using them, or can you make Python look directly at your code? Google doesn't seem to come up with anything short and to the point.
Are you using >=0.10dev? Also, have you enabled the plugin under the [components] heading in /path/to/trac-data/conf/trac.ini ? E.g.,
[components]
atompp.* = enabled
Personally, I don't really like eggs that much. I can see their use in plugins and such, but it annoys me when trying to debug them. I'm getting really sick of the "# :-)" line...
For developing with eggs, I just stick with the official trac docs. AFAICT, the only way to do trac plugins is via eggs.
I'm using 0.10b1.
I didn't actually have that line in my [components] but I do now and it still doesn't work ("No handler matched request to /atom"). I don't need to change anything in [trac] or [project] ? I'm running Trac standalone, although I doubt that makes a difference.
If what you say about Trac development is true, then appears to be a royal pain in the ass :)
It shouldn't make a difference.
Did you pull/install the atom-python branch? I neglected to mention in my original post that my trac plugin depends on my python module that reads/writes the atom format. It's still a work in progress, but it more or less does the job.
Ah yes, I wondered about that, but it's not listed on http://staff.washington.edu/marklee/bzrview/ so missed it. I see it's in http://staff.washington.edu/marklee/bzr/atom-python/ so I'll give it a go. Thanks.
well OK, that didn't help. I'll let you know how it goes :)
Try running tracd with DEBUG logging and report any errors it finds. Errors about missing roadmap or ticket modules are fine, since I haven't gotten around to writing those yet.
Great bblog I enjoyed reading
Post a Comment