nose.tools includes unittest assert methods

I came across this gem in the nose documentation today:

The nose.tools module provides a number of testing aids that you may find useful, including ... all of the same assertX methods found in unittest.TestCase (only spelled in PEP 8 fashion, so assert_equal rather than assertEqual).

Hello nose.tools.assert_almost_equal() goodbye float comparison frustration!

Managing Python Virtualenvs on Windows

I have been using virtualenvwrapper (VEW):

http://virtualenvwrapper.readthedocs.org/

for some time on my Linux desktop.  I don't do a whole lot of Windows development, but when I do, I miss VEW.  Looks like there are some solutions for Windows as well:

• https://bitbucket.org/guillermooo/virtualenvwrapper-powershell/overview
• https://github.com/davidmarble/virtualenvwrapper-win/

"cannot import name MAXREPEAT" after Python 2.7.5 Upgrade

I recently upgraded to Python 2.7.5 and started seeing the following exception when using virtualenvs:

Traceback (most recent call last):
  File "/home/rsyring/.virtualenvs/hllapi/bin/ppc", line 5, in <module>
    from pkg_resources import load_entry_point
  File "build/bdist.linux-i686/egg/pkg_resources.py", line 16, in <module>
  File "/home/rsyring/.virtualenvs/hllapi/lib/python2.7/re.py", line 105, in <module>
    import sre_compile
  File "/home/rsyring/.virtualenvs/hllapi/lib/python2.7/sre_compile.py", line 14, in <module>
    import sre_parse
  File "/home/rsyring/.virtualenvs/hllapi/lib/python2.7/sre_parse.py", line 17, in <module>
    from sre_constants import *
  File "/home/rsyring/.virtualenvs/hllapi/lib/python2.7/sre_constants.py", line 18, in <module>
    from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT

Seems to be related to older binaries with a newer standard library.  Simple fix is to change into you virtualenv directory and run `virtualenv .`

Python Distribute is now Deprecated

Just came across the news today that Distribute has been merged into setuptools and deprecated as a project:

http://pythonhosted.org/setuptools/merge.html

Targeting development versions of required packages in setup.py

Our released packages should be able to be installed just like anything else:

AuthBWC
AuthBWC==0.1.9
AuthBWC>=0.1.9
AuthBWC>0.1.9

etc.

Development versions of our packages should also be able to be installed with easy_install/pip:

    easy_install AuthBWC==dev
    pip install AuthBWC==dev

or from a requirement in setup.py like the following:

    install_requires = [
        'AuthBWC==dev',
    ],

But, the above doesn't seem to work.  I was getting errors like:

    Searching for AuthBWC==dev
    Reading http://pypi.python.org/simple/AuthBWC/
    Reading http://bitbucket.org/rsyring/authbwc/
    Best match: authbwc dev
    Downloading http://bitbucket.org/rsyring/authbwc/get/tip.zip#egg=authbwc-dev
    Processing tip.zip
    Running rsyring-authbwc-1cb0cf6b2e0d/setup.py -q bdist_egg --dist-dir /tmp/easy_install-MEGCEK/rsyring-authbwc-1cb0cf6b2e0d/egg-dist-tmp-6iqb9D
    warning: no previously-included files matching '*.pyc' found under directory 'authbwc_ta'
    Adding AuthBWC 0.1.10dev to easy-install.pth file
   
    Installed /tmp/CompWeb-build-venv/lib/python2.6/site-packages/AuthBWC-0.1.10dev-py2.6.egg
    error: Could not find required distribution AuthBWC==dev

Note that even though the package was found and installed, setuptools/distribute does not recognize version 0.1.10dev as satisfying the "==dev" requirement. 

So, I also tried:

    install_requires = [
        'AuthBWC>=dev',
    ],

Which downloaded the last released version (0.1.9), not the tip development version (0.1.10dev).  I then tried:

    install_requires = [
        'AuthBWC>0.1.9',
    ],

But that didn't work either because there wasn't anything on the pypi page pointing to a package with a version greater than 0.1.9.  That, though, was easy enough to solve, by using the following code in my setup.py file:

    ...
   
    from authbwc import VERSION
   
    NEXT_VERSION = """
    Link to tip as next version (for setup.py requirements):
    http://bitbucket.org/rsyring/authbwc/get/tip.zip#egg=AuthBWC-{0}post1
    """.format(VERSION)
   
    cdir = os.path.abspath(os.path.dirname(__file__))
    README = open(os.path.join(cdir, 'readme.rst')).read()
    CHANGELOG = open(os.path.join(cdir, 'changelog.rst')).read()
   
    setup(
        name='AuthBWC',
        version=VERSION,
        description="A user authentication and authorization component for the BlazeWeb framework",
        long_description= '\n\n'.join((README, NEXT_VERSION, CHANGELOG)),
       
        ...
    )

So, that seemed to be the end of my problems until I tried to run:

    easy_install AuthBWC

and it installed the 0.1.9post1 version from tip!

Well, I don't want easy_install installing my tip by default (Distribute's easy_install and pip did not install that version, but the original setuptool's easy_install did).  I then found this:

http://tarekziade.wordpress.com/2011/02/15/do-not-upload-dev-releases-at-pypi/

which explained some things.  Finally, I figured out that I could put the following in my setup.py file:

  install_requires = [
      'AuthBWC ==dev, >0.1.9',
  ],

easy_install seems to understand this and the result is that it downloads the package referenced on the pypi page as the 'dev' version and setuptools sees the requirement as satisfied because my tip points to source with a version of 0.1.10dev (which is > 0.1.9).

Whew! I'll be happy when distutils2 helps solve all this packaging confusion.