OddThinking

A blog for odd things and odd thoughts.

Windows Installer for PyXML 0.8.4 for Python 2.6.x and Python 2.7.x

Short version

What you’ve been searching for:

PyXML 0.8.4 for Python 2.6, Windows Installer (1,006 KB)

PyXML 0.8.4 for Python 2.7, Windows Installer (1,012 KB)

Rambling Version

So you are a Windows user and you want to install Python/XML (A.K.A. PyXML), but there is no version on Sourceforge since November 2004, when Python 2.4 was all the rage. It isn’t being maintained any more.

So you turn to your Python friends, and they say “Oh don’t use that. There are much better XML libraries now.” And you say “But the library I want to use uses ZSI which uses PyXML, and ZSI isn’t being maintained either.”

And your Python friends say “ZSI? Are you using SOAP? 2001 just called and they want their over-hyped protocol stack back.” And you say “Yeah, but I need to access a server that only provides SOAP, and someone has written a wrapper layer to it which, surprise, surprise, is no longer being maintained. Besides, the whole ‘the past called’ gag is a bit dated too, isn’t it?”

So they say “Ah, just install it with easy_install” and you look at them funny, because you are a Windows programmer, and they are Linux programmers, and that’s not the way you do things around here.

Either you decide to give it a go, or you decide to download the source directly and run ‘setup.py build’, and either way it complains about ‘vcvarsall.bat’ being missing, which is its way of saying “How am I supposed to compile this C code? Don’t you have Microsoft Visual Studio installed?” to which you say “No, I am a Python programmer now! The eighties called, and asked for their C compiler back, and I gave it to them.” but it isn’t listening to you, and neither are your Linux friends, because they don’t want to associate with someone who doesn’t have a C compiler built in to the operating system.

Maybe you discover at this point that you can actually run a lot of ZSI without the C parts of PyXML. You can just install the non-C parts. This worked for me for almost a month, but eventually it came across some XML that needed the C code and it fell over.

Then you hear a rumour about a free Visual Studio command-line compiler, and a free C compiler called gcc or MINGW or something. Sounds too hard, so you yell in frustration “All I want is a nice Windows installer with pre-built binaries? Hasn’t anyone on the internet built one for me?” and your Linux friends who were pretending they couldn’t hear you finally turn around and say “Wait, you are going to run a binary you just found somewhere on the net? Are you crazy? It could have all sorts of nasty code in there.” and you just look at them funny because that’s just the way you do things around here.

If this is you, I have a solution! I have built the PyXML distribution, ready to just install, linked at the top and bottom of this post. If you don’t trust me (and frankly, you shouldn’t), I have provided instructions on how to do it yourself.

Building It Yourself

(Much credit to psems’s instructions in this post.)

First, download PyXML 0.8.4 source. Extract it (with your favourite archive tool; I use 7zip) and extracted into a temp directory.

Now, follow these instructions heavily cribbed from this post:

1. Visit the MINGW sourceforge page:

2. Download & Run: Automated MinGW Installer (make sure you check the base, g++ and Make)

3. <Snipped>

4. Create (or edit): C:\Python26\Lib\distutils\distutils.cfg and add the following 2 lines:

[build]
compiler=mingw32

Step 3 said to “Update your PATH: Add the C:\mingw\bin directory to the system PATH”. I was once bitten by Cygwin in 1998, which totally broke a whole lot Windows scripts by inserting itself in my path. Cygwin and MINGW have similar goals, and I am still superstitious about this, even though I should get over it. I added MINGW to my path temporarily, see below.

Okay, now go the command line, and get yourself into the temp directory.

Add MINGW to your path temporarily by typing PATH=%PATH%;c:\mingw\bin\

If Python 2.6.x isn’t already your path, do a similar command like: PATH=%PATH%;c:\Python26, or just type c:\python26\python in front of every command below.

(Or similarly for Python 2.7.x)

If you just want to install it, type:

setup.py build
setup.py install

This time there should be lots of output but no errors.

If you want to do what I did, and create a distributable installer type:

setup.py bdist_wininst
setup.py bdist

The first one contains an exe, which is what you wanted. The second one creates a zip, which some people prefer. You will find them in the dist subdirectory.

Once you have the exe, you know how to install it – good ol’ double-click! How embarrassing for the Linux people that they have to type “easy_install”, which means it is already far too hard for us Windows folks!

Check it worked by typing starting python and typing import xml.dom.ext.reader; it shouldn’t give an error.

The Results

PyXML 0.8.4 for Python 2.6, Windows Installer (1,006 KB)

PyXML 0.8.4 for Python 2.6, ZIP archive (1,310 KB)

PyXML 0.8.4 for Python 2.7, Windows Installer (1,012 KB)

PyXML 0.8.4 for Python 2.7, ZIP archive (1,316 KB)

Licence

It should be obvious, but I am not claiming any ownership of this code. Nor am I offering any warranties. It should be used subject to the copyright notices and licences included, which give credit to the people who actually contributed to the project.

All of the original code is available from Sourceforge.

25 CommentsCategories: S/W Dev
Tags: Python, PyXML

Comments

  1. I don’t understand something. A compiled executable can contain whatever code the untrustworthy developer wants, but so can the actual code. Do those Linux friends read and understand every line of code they download?

    I’ve always been perplexed by this. The only times I download software from untrusted sources are code samples, in which case I download the source and read it anyway. Otherwise, I’d go for the binary anytime (and hope for the best)

  2. It is a fair question and a complex area filled with lots of assumptions.

    a) That bad code is easy to see if you are looking for it. I’ve seen code that designed to look innocuous at first perusal, but actually does bad things.

    b) That the bad code isn’t hidden in layers you can’t see (Ken Thompson-style)

    b) That sufficient eyeballs are available actually looking at the open source code. For popular Python packages, that seems fairly likely. If you are installing something esoteric that might not be true.

    I think it is fair to say that downloading a binary from the site that also offers the original source is safer than downloading the binary from an untrusted third-party.

    (As much as I would like the trust of random people who discover this site by search, I think the world would be a safer place if they treated random blogs with suspicion.)

  3. I am very amused by your narrative, and appreciative of your efforts. Surprisingly appreciative for someone who doesn’t actually use XML for anything, and thus most likely doesn’t (yet) have any use for PyXML.

    I’m appreciative mainly because I’m also a Windows Python user who has deep misgivings about Cygwin but will use MinGW in a pinch. I don’t think you should put any pressure on yourself to “get over” your issues with Cygwin, because of what it aims to do, which is to turn your Windows machine into a quasi-Unix work-alike development environment.

    From my point of view, the goal of MinGW is not terribly similar to that of Cygwin, though this is confused a bit because there are two flavors of MinGW: with and without MSYS. (Well, in classic Unix tradition, MinGW and MSYS are technically independent, but there is practically no point to MSYS without MinGW, and those who like MSYS will naturally assume that anyone who uses MinGW should want to use it with MSYS. Thus, when those people say “MinGW” they mean “MinGW with MSYS”.)

    The more minimal flavor is of course MinGW without MSYS, and this is what I am reasonably comfortable with. In this setup, MinGW seems to be trying to just be a command-line compiler. Your Windows is still Windows, your command prompt is still essentially DOS. It’s closer to ’80s-style compilers for DOS.

    MSYS corrupts this, and is (as I perceive it) part of the way towards Cygwin. So I believe you should continue to be wary of Cygwin, and perhaps be even more wary of MSYS (because it is sometimes insidiously portrayed as an essential part of MinGW). But as long as you keep your system MSYS-free, I think you shouldn’t have much trouble with MinGW.

  4. The idea that source code is safer than binaries is because truly innocuous source code is (very relatively!) easy to verify as such. In contrast, innocuous binaries are not easily so verified.

    When the code isn’t easy to verify as innocuous, of course, then the complexity of examining source code is no different at the limit from the complexity of examining a binary – after all a binary too is just source code, it merely happens to be written in machine language. And any high-level language listing can be made just as difficult to comprehend as a large machine language listing.

    The idea behind the assumption of the safety of source is that anyone who downloads it could inspect it. Not everyone will, obviously, but presumably a few people are going to – from which everyone else then benefits. Of course, whether this assumption turns out to be justified varies wildly from project to project.

    So basically what happens when you offer up source code for download is that a number of factors come together to make it easier to increase the trust in it if it’s actually good code. However, contrary to what most people assume, having the source code does little to expose malevolent code as such.

  5. Which of the various Python Windows runtimes is this binary going to work for? I know that the ActivePython 2.6.3.7 distribution I just installed is linked against MSVCR90.DLL, which as far as I know is not what a mingw built binary would link with without some coercion. If your mingw built DLL is linked to MSVCRT.DLL from Visual C++ 6 (the default) and you’re using it with ActivePython, then you’re going to have a bad time whenever the garbage collector wants to free some memory your DLL malloc’d. It’s incompatibilities like these in Subversion, Python and Apache that make using tools like Trac such a joy. C runtime DLL hell continues its evil work…

  6. Richard,

    Short version: I have no idea. You’ll have to look for yourself.

    Longer version: I’ve never looked at the Python/C interface, but I would have thought the garbage collector would call the object’s __del__ method which would be responsible for calling the C code and telling it to clean up after itself. I wouldn’t have thought the garbage collector directly cleans up memory used by the DLL. I haven’t thought this through very far.

  7. What do we do for a 64-bit version of PyXML in python 2.6?

  8. Oh oh oh you have just saved me. Three hours of PAIN solved with your simple installer. Thank you!!

  9. Py XML is a good program
    I need him for help blender and crystal space to work together

  10. Julian, thank you so much for this, saved me a few hours for sure!

  11. Updated with binaries for Python 2.7.x.

  12. Oh,Thx a lot,If I havn’t visited here,maybe I have gived it up

  13. tks a lot

    i love you

  14. Thank you very much. You saved my day.

  15. Thanks but I still get same error message when I tried to use it from SF.net which is:

    error: compiling 'C:\Python26\lib\site-packages\_xmlplus\xpath\ParsedAbbreviatedRelativeLocationPath.py' failed
    SyntaxError: invalid syntax (ParsedAbbreviatedRelativeLocationPath.py, line31)

    I think the problem related to “as” keyword.

    Do you’ve any solution?

  16. Sounds like you are stumbling over this bug in PyXML.

    (Yes, “as” became a reserved word in Python 2.6.)

    You may need to apply the patch described there.

  17. fcking awesome dude

  18. Have you tried build this on win 64, I did but no succeess

  19. Sorry, Tran Khai Hoang, I can’t say that I have. I have never compiled any C for 64-bit Windows.

  20. Thanks for your efforts! Exactly what I was looking for…

  21. Installation using the installer is aborted on Windows 10 64bit without a meaningless errormessage, basically “Its not running, screw it, will not install, regards, Windows”.

    What now? Just slam the zip content into phyton27, even the topmost subfolder in the zip was python26. Is this working?

  22. all Web Mentions are dead links.

  23. Arne,

    I’m afraid these are 32-bit installations.

    I’m not surprised it doesn’t work on 64-bit installations, but a meaningful error message would have been nice.

    You’ll need to rebuild them as 64-bit. I have no experience with that.

    My supplier finally moved over to use REST, at about the same time my project that was mothballed, so I don’t have any use for PyXML any more.

  24. I removed the broken Web Mentions, but it is the nature of the web that these things are going to be everywhere.

Leave a comment

You must be logged in to post a comment.

Web Mentions

  1. SOAP with Python | aheil