Python Multi-Build for Python Extensions Packaging - Report 2

Hello,

This is second report of my GSoC project for Debian. Since my last
report I have done most of things about my project's design. Me and my
mentor are thought about projects API, design etc. this two weeks. Since
preparing API is the most important task of this project two week is not
a long time, and I don't say that API design is over. According to your
comments or requests I can change the API.

If you want to see how the tool's API look like or tool's source code you
can clone project's git repository at [1]. In repository, under template/
directory you can see that.

Under the directory you will see one file and one directory. Only file is
the tool's main file, called py3build. It is a python3 script. It will
build extensions for Python3.

Firstly It will parse arguments. Arguments are:

--system args: (extension will be build for which build system)
--test: (for only test the extension)
--no-clean: (don't try to call clean method)
--configure-args args: (extra configure args)
--build-args args: (extra build args)
--test-args args: (extra test args)
--quiet: (quiet mode)
--verbose: (verbose mode)
--python-version args: (build for that version)
--build-directory args: (build in given directory)

If there is no given Build System then It will try to get Build System
list. This list will be generated from plugins/ directory which you can
find under my git repository's template/ directory.

I want to describe what will BuildSystem's look like.

Under plugins/ directory you will see __init__.py file. It will contain
base BuildSystem class, main Exception class, and other method specific
Exception classes. (f.e. ConfigureError) Main Exception class will be
derived from Exception class and other Exception classes will be derived
from this class, called Error.

Base BuildSystem will be derived from all other Build System classes. It
has __init__ method which gives build_dir, configure_args, build_args,
test_args for parameter. It will set them to self.{parameter_name}. So,
if they will be needed from another method, can be retrieved from
self.{parameter_name}, no need to pass every method.

One of the important BuildSystem class method is detect method. This
method will detect the extension's build system. If given directory has
files for building extensions for this build system (or other magical
detecting ways) it will return true.

After that with configure method we can configure extension for the build
system. This method and other methods in build system classes' will also take version parameter. This parameter will
determine that this extension will be build for which Python version. If there is
any error occurs then it will raise ConfigureError exception.

Clean method will cleans (f.e. removing build files) given directory for
that build system. If there is any error occurs then it will raise
CleanError.

Build method will build extension for the build system. It will use
self.version to determine which version it will be built for. If there is
any error, then raises BuildError.

Last method is called test. This method will test the extension for
self.version Python version. If there is any error occurs then raises
TestError.

Every build system plugin should have one class, same name with file. The
class should extend BuildSystem class and override this class' methods
for working correctly.

I also wrote an example plugin, called example. For show how it will be done (It is under
plugin/ directory under project's git repository).

py3build's get_build_system method will retrieve a BuildSystem list. This
method will be used by determine_build_system method. That method will
determine which build system is usable for this extension. After that
this method also returns a list. List is in order to higher probablity to detect.

Main method will invoke clean_for_build_system with a BuildSystem object
argument for clean for that BuildSystem, configure_for_build_system with
a BuildSystem object argument for configure for that BuildSystem,
make_for_build_system with a BuildSystem object argument for build for
that BuildSystem and test_for_build_system a BuildSystem object argument
for test for that BuildSystem. The call sequence is like that.

Every method will return True if everything is OK.

We are still working on API and this one isn't completed, and
discussing about various problems.

[1] git://git.debian.org/~mesutcan-guest/py3multibuild.git

Python Multi-Build for Python Extensions Packaging - Report 1

Hi,

This report is first official one for Debian Google Summer of Code. My project is creating a tool to build Python extensions for all Python versions supported by Debian. I've added my project proposal to Debian Wiki before I submitted. You can see it at [1]. I'm also writing a blog, [2]. You can see my posts from Debian Planet.

I didn't start coding for the tool until today. This week I'll start coding. My final exams are ending at this Friday (10 June). This is why I didn't started coding. I don't want to start coding at the beginning of my exams because I can't fully concentrate on coding.

Before writing and during writing the tool I'll decide this tool's
methods and what they do with my mentor Piotr and Debian-Python list
[3].

For investigating what CDBS and dh sequencer are doing right now I read

* /usr/share/cdbs/1/class/python-*
* /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm

files. They give me enough information what is going on right now.

I won't try to feel developers strange when they using this tool via
CDBS and/or dh sequencer.

For first, I'll write a tool to create Python 3 extensions. I think
creating Python 3 extensions have a bit higher priority.

Coding period is something like that:

* Writing a method to detect which build system will be used.
* After detecting build system, check everything is sane.
* Start building package:
* Make tests which are supported by build system. (f.e. in
autotools, *make check*)
* If needed, compile.
* Build package.

I decided to start writing for Python distutils first. I think this one is more important than other build systems. So, after I finished building extensions using distutils I want to give it to developers who can test the tool, and if they find bugs or something should be added, I will add these things. After I finished and give developers to test tool for each one of build system, I will start writing for next build system.

I'll use PEP8 standards for coding. I'll develop my project using GIT, my repository is under Alioth. You can clone this project's repository. For now I created only one repository for building python3 extensions [4]. Firstly It will be written in Python3. I'll write a py3to2 converter and make running this tool using >= python2.6.

I didn't do much things, especially didn't started coding and naturally report is short, but next report will be much better (more detailed and more technical) then this one.

[1] http://wiki.debian.org/SummerOfCode2011/PythonMultibuild/mesutcankurt
[2] http://mesutcaneng.blogspot.com
[3] http://lists.debian.org/debian-python/
[4] git://git.debian.org/~mesutcan-guest/py3multibuild.git