August 27, 2004
Jim Hugunin on Interactive Python

Jim Hugunin, the inventor of IronPython (Python for .NET) has got a blog and for his first post gives examples of using IronPython as an interactive scripting environment for .NET. I'd never really thought before about just how useful the interactive aspect of the language could be, but it's excellent. This combined with tools like SnippetCompiler from Jeff Key could be incredibly useful in cutting down the time taken to experiment with code.

I downloaded IronPython recently and used it to briefly prototype a piece of code for experimentation purposes, and it's definitely cool. I love the simplicity of Python code, and being able to import all the really cool .NET framework classes and use those with Python code is sweet. Now what we need is for the base Python libraries to be available alongside the .NET framework in one place.

One thing that seems to be missing at the moment is a pycl tool, an actual compiler. I could only find the interactive run-time with the distribution, but hey - it's only an alpha!

Posted by Simon at 11:49 AM
August 04, 2004
New tool setup constants

From the "what's new and good in PN2 0.5.5" department:

In PN2 0.5.5 you can now get the project and project group paths when building up tool parameters. You can't find these constants in the interface yet, as they use a new scheme that has only just been introduced. The next version will make this more obvious but for now, here are the constants:


Remember all paths include a trailing path separator. If no project or project group is open and valid then these constants evaluate to nothing.

In the future I will be moving more towards this more expressive type of constant and away from the old type, %x constants prove difficult to remember.

Posted by Simon at 08:04 PM
August 03, 2004
Versioning Common Components

At work we have a set of inter-dependant components (a lot of which I have written) that are used in multiple products. It's important to keep all shipped versions of components so that when debugging we can use the correct component parts. There are several problems to overcome when working with components like this:

  1. the components do not change all at once, but because they have dependencies on each other they need to be built as a set, or we have complicated version mapping issues.
  2. the version numbers: we could either version all the components as a set, but this hides what components have been updated in the builds. We chose to not tie the version numbers, but this means that we need to be able to identify the correct set of versioned components.
  3. keeping the sets identifiable for debugging at a later stage.
  4. changing references to assemblies in visual studio .net is a pain, especially if the project is in source control.

I needed to develop a strategy for use and versioning because managing this lot manually was becoming a time-waster. This post details what I came up with, and in response I hope to hear other people's solutions to the same problem.

We keep a shared components directory on a server, called \\Server\SharedComponents (names changed to protect the innocent). This directory holds all shipped versions of the components, and also the current development ones. Inside that directory, there is a directory called Head. Inside head are placed the most recent builds of components that work as a set. These components are all built at the same time using a NAnt script. In fact, that's a bit of a lie because some Managed C++ bits won't build with NAnt at the moment so are done manually but in an ideal world...

The projects that we work on that use these components use the head build while in development. When the product is preparing for a release, we use the following steps:

  1. Copy the known-good set of components into a dated directory, e.g. 20040803
  2. Branch the product in source control and use a python script to check the projects out, change all the project references to point at the now stable components distribution, and check the projects back in again (with a suitable change log message, of course!).

We now have a fixed set of components for one release, and with very little effort all of the references are changed to use this build. In the future that branch can be checked out and all will be as it was on the day of release!

This solution is not perfect, identifying a set of components can be slightly hard and there are still issues with keeping change logs for component sets up-to-date but it's a step in the right direction (for us, at least!).

So tell me, how do you solve this problem?

p.s. I'll post the python script here at some point for those interested.

Posted by Simon at 12:11 PM