Saturday, December 17, 2011

Setting environment variables for MSBuild Exec tasks

MSBuild has an <Exec> task for calling external programs, but (bafflingly) it doesn’t allow you to set the environment the program runs in. In my case, I need to run a Python script with certain directories in the PYTHONPATH.

The Short Way

On Unix machines, this is trivial:

PYTHONPATH=”~/foo” python script.py

For Windows’ wonderful cmd.exe shell (which MSBuild uses to run Exec) it’s a little longer:

(set PYTHONPATH=C:\Foo) & python script.py

If you want, you can chain multiple set commands together to set multiple variables:

(set PYTHONPATH=C:\Foo) & (set FOO=42) & python script.py

To actually use this in the MSBuild file, you’ll need to escape it like so:

<Exec Command=”(set PYTHONPATH=C:\Foo) &amp; python script.py” />

Getting the quoting right for <Exec> can be tricky; I use the <Message> task for debugging the command line. Remember to use &quot; instead of double quotes.

The Long Way

This method takes more typing but is a bit more clear, especially if you have multiple variables to set. Actually, it can be used to store whole batch files inside the MSBuild file, if necessary.

<PropertyGroup>
  <PythonExec><![CDATA[
set PYTHONPATH=C:\Foo
set FOO=42
python script.py
  ]]></PythonExec>
</PropertyGroup>

<Exec Command="$(PythonExec)" />

A CDATA section is required because the newlines need to be preserved. When running an <Exec> task, all MSBuild does is write the contents of Command to a temporary batch file an execute. This just provides more than the usual single line command.

Monday, December 12, 2011

IronPython 2011 Survey

The IronPython team would like to know more about how IronPython is being used and what improvements people would like to see in 2012.

Take the IronPython 2011 survey!

Sunday, June 12, 2011

NWSGI 2.1 Now Available

I’ve finally updated NWSGI to use IronPython 2.7: NWSGI 2.1. The only other change is that NWSGI.dll will be added to the GAC by default by the installer.

NWSGI 3 Update

The big feature of NWSGI 3 is decoupling it from IIS and ASP.NET, which involved creating an abstraction layer for web servers (which is funny, because that’s what WSGI is). Shortly after I started that, the OWIN project started, which has essentially the same goal. Since I hate duplicating effort, NWSGI 3 is on hold until OWIN stabilizes, which hopefully shouldn’t be too much longer.

Thursday, February 10, 2011

First IronPython Bug Weekend Coming Up

The first IronPython Bug Weekend is this weekend, February 12-13, 2011. The purpose of the bug weekend is to get as many issues as possible looked at and fixed before the next pre-release of 2.7. There are a large number of issues in the issue tracker that need to checked to see if they are still valid (based on what I've seen, probably half of them are already fixed). If they're not reproducible, they can be closed; if they are reproducible, then patches are always welcome!

In particular, we'd like to get people who haven't contributed to IronPython before to chip in. It's really not that scary, I promise! To get started, check out how to get and build the source code and how to handle issues. If you have any questions, just ask – everyone is willing to help out.

To get in touch with the other bug weekend participants, there are two primary channels: the mailing list (sign up, view the archives) and the #ironpython IRC channel on freenode.net. If you're looking at a particular bug, make an update to the Bug Weekend spreadsheet, and make sure no one else is working on it either. It's a good idea to send a message on IRC or the mailing list as well.

Here's to a good bug-fixing weekend!

Monday, February 7, 2011

IronPython 2.7 Beta 2 Now Available

At long (long) last, the first community release of IronPython is now available – IronPython 2.7 Beta 2. The highlights of this release are the new zlib (which also enables gzip) and subprocess modules. There have also been a number of bug fixes.

Since Beta 1, we've moved all development to the Github IronLanguages project, although the issue tracker is still on CodePlex. This meant learning the build system, learning how to package a release (something that needs some work), and various other odds 'n ends. There are definitely some stumbling blocks that new people might trip over, so those should be taken care of as soon as possible.

The next release is scheduled for February 20th. The first IronPython Bug Weekend is scheduled for February 12-13th; more on that coming soon.