–debug=ALL

As I have mentioned in 15 earlier blog posts, my current project is putting together an accessibility API comparison framework specifically for browsers, and help weed out substantial differences in implementations.

The challenges I have faced, and still sometimes face:

Windows

I was surprised to learn that Windows is still by far the most popular platform in the world. Interesting. Since it isn’t very POSIXy, I have had a lot of dillemas as how to distribute software for it. The usual autotools, or distools does not have all the advantages it has on Linux or Mac OS X. On any other OS, you could safely assume that Python is installed. Not on Windows. In the last few releases I have been experimenting with py2exe. It gives you a bit of a DOS feel to your package: unzip and run the first EXE you see. Easy, but unelegant.

Selenium

One of the first things that turned me on to Selenium was that it was platform, browser and language agnostic. What better way to provide users with absolute freedom in choosing their language and platform? Originally I subclassed Selenium’s Python client class, and added all of the accessibility functions to it. But I decided it would be awesomely cool if this were added to the Selenium server itself, so that the integration with accessibility would be tight and native, and language agnostic. After installing a couple dozen dependancies, and reading Selenium’s developers guide more than once, I finally made the proper changes in Selenium Core and Selenium Remote Control to support accessibility tests. This created a huge overhead for anyone who would want to build the entire solution from source who is not me. They need to check out my git versions of Selenium Core and Selenium Remote Control, figure out how to build them, fail, try again, etc. Selenium has many advantages, but building it is a real pain.

While Selenium is great, I have had a hard time interfacing with it’s community, besides a few individuals. The changes I made to selenium only made sense if they somehow landed upstream. I don’t see that happening any time soon, so folks who want to use my solution are doomed to using a fork forever. Unacceptable!

So I decided that in the next Speclenium release, I am going to go back to the simple approach of subclassing the Selenium Python client. This will hopefully simplify the setup overhead since we could instruct people to just go to Selenium’s website and download an unmodified binary. The downside, is that tests could only be written in Python, and not in Ruby or PHP. I think that is an acceptable loss.

I already have a branch with the appropriate changes. There will be some dramatic file renaming going on too, not for the first time.

Selenium vs. Windmill

Since I started work with Selenium, I have been called attention to Windmill more than once. For one thing, it seems like Windmill will be the tool of choice for Firefox QA. With components such as MozMill, and Gristmill Firefox QA could do some automated chrome testing action. Recent real-world cases have come up in the Firefox world in which such in-app interaction would be beneficial. Currently the Selenium setup is specifically targeted at the document frame, and nothing above it. This has been the choice since ultimately we are looking for browser independance.

Windmill is written entirely in Python, which would compliment my project well.

So why not switch to Windmill just yet? For one, it would be a distraction, I am pretty far along in the project, I would hate to suddenly switch the whole toolset. Second, I have a feeling that Windmill does not have the same wide support for browsers as Selenium does. For example, Selenium already has the proper bits for automating Google Chrome. I am repeatedly impressed by how easy it is to launch and automate obscure browsers using Selenium.

I know that Windmill has been under intense development this summer, so it might get really good soon. Nonetheless, I think that this accessibity testing project might eventually benifit from a side-by-side approach of support for both Selenium and Windmill.

That is my brain dump for now. Aren’t you glad I don’t do that often?

–debug=ALL

5 thoughts on “–debug=ALL

  1. Having been trying to solve a similar oh-no-can’t-depend-on-Python-being-installed Windows distribution problem recently, I should note that py2exe supports bundling everything into one single exe file, which means that your users don’t have to open the zip file and run the first exe; they just download an exe and run it.

  2. Eitan, re deploying on win32: I use py2exe to create the stand-alone dist and then INNO setup to create a windows setup.exe. It works well – e.g see powertalk tarball where I use a cmd script to drive it all. http://prdownloads.sourceforge.net/powertalk/PowerTalk-1.2.11Src.zip?download

    INNO is declarative but you can script with PASCAL when needed

    py2exe seems to be the best solution at the mo but there are a couple of others. It does run into occasional problems with things like pywin32 which does clever module location manipulations, but as it’s python you can work around them.

    Steve

  3. ethana2 says:

    A comment from the idealist in me:

    Just throw it all into an .exe. If they don’t want bloat, let them use an OS with real package management.

  4. heh.
    I was going to add that windows users expect installers to do more than install/upgrade – like add an uninstaller, update registry, add icons to start menu / desktop blah blah blah.

    I was wondering why we don”t have pm on windows and I guess it largely historical. Mind you I wouldn’t be so happy with MS being the repositry managers (as it’s their distro) and having to deal with them for all my projects. So we’re stuck with the chaos and delights like DLL hell or its big brother side-by-side. Joy.

Comments are closed.