Posts Tagged ‘Django’

Surfing

Tuesday, January 12th, 2010

Sometimes I get lost in the Web, just following links after link for new ideas, following a vague plan of action, multiplying tabs and relying on browser’s session restore capabilities and tab and bookmark syncing.
Tonight, after a full day of work, the gym, the dinner and some chatting with my lovely wife, I had one of this session on the sofa (thanks to netbook magic, the fully working Samsung NC10 with F12 and about 4hrs battery life..).
Anyway, I discovered some interesting projects. the first is a Django powered software forge (think sourceforge plus trac): basie is a MIT licensed software which is growing up from an academic world, and I shall admit to find it intriguing, and an interesting candidate to the trac position.
Next one is the Python Buildhaus Project, which goal is to setup a build system for Python packages against multiple architectures / OSes / python environments: infrastructure will be provided by the Snakebite project, which goal is to make available as many platforms as possible to test open source software builds.
Finally, a nice old blog entry regarding TDD AntiPatterns.
Lot of stuff. Will keep an eye on those (and perhaps contribute to basie, who knows…).

Pinax Dependencies – django-extensions

Monday, August 24th, 2009

Ok, so I checked Pinax dependencies and found some external libs to be packaged before being able to completely package Pinax. This packages will form the “depends” line of Pinax itself.

Looking carefully, the first one is named django_extensions, but really the name should be “django-extensions”, and you can find the project with the not intuitive name of “django-commandline-extensions” here at googlecode.

Ok, let’s see the spec file:

%{!?python_sitelib: %define python_sitelib %(%{__python} -c “from distutils.sysconfig import get_python_lib; print get_python_lib()”)}

Name:           django-extensions
Version:        0.4.1
Release:        1%{?dist}
Summary:        Django command line extensions

Up to this point, standard stuff. The {?dist} should stand for “current distribution”, so it will end in a “fc11″ package.

Group:          Development/Languages
License:        BSD
URL:            http://code.google.com/p/django-command-extensions/
Source0:        %{name}-%{version}.tar.gz
Source1:        %{name}-docs-%{version}.tar.gz

The Group is standard for Python / Django libraries. License is taken from the project’s homepage, source is the standard .tar.gz file which is downloaded from the front page of the project. Source1 is extracted from the github 0.4.1 tag of the project and contains just the documentation to be built.

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch:      noarch
BuildRequires:  python-devel python-sphinx
Requires:       Django

%description
This is a repository for collecting global custom management extensions
for the Django Framework

The buildroot path is standard, arch is noarch (just python code…), the build requires gets the addition of python-sphinx (python documentation generator) which, at buildtime, generates html documentation from .rst files. Obviously runtime requirements are Django, while the description is a copy and paste from the project home page.

%package doc
Summary:        Documentation for django-extensions
Group:          Documentation
Requires:       %{name} = %{version}-%{release}
Provides:       %{name}-docs = %{version}-%{release}
Obsoletes:      %{name}-docs < %{version}-%{release}

%description doc
This package contains the documentation for the django-extension library

Wait a minute, what is this? Exactly, we are building not one but two packages. One for code, one for doc.

%prep
%setup -q -n %{name}-%{version}
%setup -a 1

Ok, now things become interesting. According to both the Fedora Project RPM Guide and the Maximum RPM book on rpm.org, the above section reads as: prepare environment; extract first source file silently in a directory named $name-$version (e.g. django-extension-0.4.1), then extract the second source file after changing directory to the newly created directory. This is necessary because I compressed just the docs directory level in the git-donwloaded file.

%build
%{__python} setup.py build

%install
rm -rf $RPM_BUILD_ROOT
%{__python} setup.py install -O1 –skip-build –root $RPM_BUILD_ROOT

(cd docs && make html)

All this stuff comes standard creating an empty python spec file, apart from the last line, which builds the html documentation. This is suggested also by Django spec file (go get it with a yumdownloader –source Django and rpm -ivh the src.rpm).

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%{python_sitelib}/*

Standard stuff again.

%files doc
%doc docs

doc packages files

%changelog
* Sun Aug 23 2009 Luca Botti <lucabotti…fedoraproject.org>
- Initial RPM Release

changelog description.

This file is uploaded at my fedorapeople.org’s address and is submitted in bugzilla for review here. I am waiting for sponsorship. Thanks.

More packages will follow. Stay tuned.

Building RPMs, part two – Pinax

Sunday, August 23rd, 2009

Ok, so now we have the environment complete. First thing I want to package is Pinax. This is a nice little collection of Django applications which add some required stuff for most of web based applications.

On the link above you will find all the info for the project, so let’s start. We will build the release version of Pinax (for development versions I have a side project, which I will show you at right time). Please note – all the release used are current for the day this entry has been written.

Download pinax version 0.5.1 from here and put it in rpmbuild/SOURCES. After that:

cd ~/rpmbuild/SPECS

rpmdev-newspec -t python pinax

Rpmdev-newspec creates the skeleton for a new spec file named pinax. The -t python option tells to create a skeleton with some python definitions in it (python definitions are laid out according to this wiki entry on the Fedora Project Wiki); you can see which skeletons are available looking in ‘\etc\rpmdevtools’.

Why Python? Well, my guess is that being DJango a Python framework, you know….

Let’s look at the spec file and put some info into that. You can use any editor for the file (I use geany, fast and lightweight).

# sitelib for noarch packages, sitearch for others (remove the unneeded one)
%{!?python_sitelib: %global python_sitelib %(%{__python} -c “from distutils.sysconfig import get_python_lib; print get_python_lib()”)}
%{!?python_sitearch: %global python_sitearch %(%{__python} -c “from distutils.sysconfig import get_python_lib; print get_python_lib(1)”)}

Name: pinax
Version:
Release: 1%{?dist}
Summary:

Group: Development/Languages
License:
URL:
Source0:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch:
BuildRequires: python-devel

I am assuming that Pinax is a pure python package, so we use the sitelib for noarch packages (first line of the two provided). After that we have to insert some descriptive info of the Pinax project.

But, of course, before going ahead we must check some of the Pinax dependencies.

Continuing tomorrow…

Getting lost

Thursday, June 25th, 2009

At Byte-code meetup I just launched the idea for a new projet to support the Prince2 project management methodology.

Right now, I just registered at sourceforge and nothing else. But the plan is clear (and will be managed in a Prince2 manner, by the way):

  • Django / Python powered
  • GPL v2
  • Integration with external tools ( trac comes to mind, but also taskjuggler )

Django is a little hazard – never programmed seriously in Python, and the Django world is a new one for me. Anyway, I am just willing to move away from the Java world for a while.

Now comes the best – I will try to do it using Fedora way . This means that every additional package (Python or Django) will be rpm’ed.

Django by itself it’s a no-brainer – just yum install Django (observe the capital ‘D’ here), but I was looking at Pinax and some more Django extensions, mostly hosted at google code.

Benefits of this plan:

  • Enhance package building knowledge
  • Easy installation
  • Really join fedora community

So I will create a new category, starting today, where I will summarize my steps. Stay tuned.