setuptools_bzr

If you have a Django application (or any Python project) hosted on Bazaar (and also svn, git, hg), you can add a setup.py script to install it with the awesome pip tool, for example:

pip install -e bzr+http://bazaar.launchpad.net/%7Edjango-wikiapp/django-wikiapp/main/#egg=django-wikiapp

This requires that your users have bzr, so lets release and upload a tarball to pypi! But first you will need Bary Warsaw's setuptools_bzr (pip install setuptools_bzr) plugin so it can find all (non-python) versioned files, like .html templates used by inclusion_tags and etc. It will also reuse the ignored files rules. Just add this to your setup.py:

setup(
...
setup_requires=['setuptools_bzr'],
)

After you upload your tarball, your users will be able to install your app like this:

pip install django-wikiapp

Thanks jezdez on #pinax for the setuptools_bzr tip.

bzr grin

grin is a grep-like tool written in Python. I've been using it recently and its great.
So I had an idea: integrate it with Bazaar, to search only on versioned files. It would be a good simple exercise to learn both bzr and grin's APIs to write plugin to add a "grin" subcommand to bzr, but I've found a simpler solution: use the extcommand plugin and add this to my bazaar.conf:

[EXTERNAL_ALIASES]
grin = bzr ls --versioned --kind=file | grin --force-color -f - $1

All because I wanted to do "bzr grin something"...

Some Thoughts about a Django Template Mode for Emacs

I keep a Emacs mode for editing Django templates (specifically HTML Django templates) on Launchpad. There are more people interested in enhancing the support for Django on Emacs, and I'd like to help. But first, I want to discuss what is needed from a editing mode.

Syntax highlight for tags

Should syntax highlight work for any tag (anything between {% and %}) or only 'known' (built-in) tags?
The pros-cons I can think of are:

• Any tag
  
  
  • Would highlight custom, loaded tags
    
  • Would highlight unknown tags/typos
    
  
  
• Only built-in tags
  
  
  • Help to identify typos and such
    
  • Would not highlight new, included tags
    
  
  

The simpler solution is to highlight this kinds two differently. But it may also be possible to parse the "{% load %}" tags and highlight only the built-in or loaded tags. Opinions, please!

Syntax highlight for vars

I guess this point is pretty much uncontroversial, but I have a question: would you like it to highlight vars, filters and its arguments (like "{{ var|filter:args }}") differently? I dont have a strong opinion on this. Also, filters raise the same question that I made for tags earlier.

Should it be sgml-mode based?

Right now, django-template-mode extends the standard sgml-mode. But what about non-html templates, like Json? Should we support must common formats? Should we have a variation for each one? I know I'd like it at least to recognize HTML, as it is now.

What about indentation?

Currently, django-template-mode deal with indentation of template tags as it was text. I know that Indentation is a little more tricky problem, but I'd like to have it, If possible. Do people indent template tags the same way they indent python code?

Autoclosing

Django-template-mode supports auto-closing of tags. Do you think it is a valuable feature?
There are two possible types of auto-closing:

• {% and {{
  
• tags ({% if %} -> {% endif %}, etc)
  

Finally, how people work with django templates on other editors? I know some editors have basic support for django templates already. How they deal with the questions I made here?

Compiz+Firefox bug

Seems like I was experiencing this bug. I'm using the workaround cited on the bug report, disabling the legacy fullscreen support.
Now I'm curious how the reporter found this workaround.

Quick note: Django Events

A new resource for the Django Commuity was released today: Django Events, by Marty Alchin (aka Gulopine). Go on and explore the already-registered events. See also Marty's plans for it on his blog.

How I (think I should) use Launchpad

Launchpad is, so far, my preferred code-hosting service. It surely could use a better, more 'compact' design, like Github, but I like the focus that lp gives to projects and teams, and its integration with Bazaar.

Here I describe the workflow I think that works best for me when using Launchpad and Bazaar.

Launchpad uses stacked branches so each branch don't need to store the whole history of the project . Locally, if we want to work with various branches, we can use a shared repository, assuming that the project have a "trunk", or main branch.

Start by creating the repo:

bzr init-repo PROJECT
cd PROJECT

Get the project's main branch:

bzr branch lp:PROJECT trunk

Get any other branch you may want to work with:

bzr branch lp:OTHERBRANCH

Derive your own branches, from trunk for example, to work on some task:

bzr branch trunk mybranch

Another option is to work with stacked branches. I don't see many advantages to work with locally compared with shared repositories, but lets imagine that you already have a standalone branch for that big project that you wanted to take a look at, and suddenly you see yourself wanting to hack it! You can do it on a stacked branch:

bzr branch PROJECT mybranch --stacked

'mybranch' will be 'stacked' on 'PROJECT'. Lets say that PROJECT was at revision 42: any time you want to work with a revision (check the log or diff, for example) older then 42.1, bazaar will look for the revision info on the PROJECT branch.

Also read: Choosing a shared repository layout.

How do you work with Launchpad? And if you use other service (eg. Github, Bitbucket), how do you organise multiples branches locally?

Happy New Year!

New year, new blog.

My intention is to update this blog more regularly them my Advogato diary (why Advogato? I really cant remember), with similar content, but with more quality.

Also, I'll try to keep track of stuff I'm learning here, like new APIs and any geek stuff, so please be patient if some articles are too shallow -- It will improve, I hope. '101' articles and personal stuff will be tagged accordingly, too.

So, happy new year everybody, we'll meet again soon.