virtualenvwrapper 4.7.0

This release improves MSYS support for 64bit systems.

What is virtualenvwrapper?

virtualenvwrapper is a set of extensions to virtualenv. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies.

What’s new?

  • Detect MSYS if MSYSTEM is MINGW64 (contributed by Martin Etnestad Johansen)
  • Update documentation to show how to restore overridden cd command to its default builtin behavior if it was changed in a hook. (contributed by Kevin Deldycke)

Migrating back to WordPress

I’ve migrated my personal blog from Tinkerer back to WordPress, which may introduce repeated articles into the various RSS feeds, since the URLs have changed.

The primary reason I decided to change blogging tools is because with more than 500 posts, the site build time under Tinkerer was unacceptably long. It works great for someone familiar with Sphinx, and with a smaller amount of content than I have.

The reason I chose WordPress over another static blogging engine is I want to be able to schedule posts to be published in the future, without having to set up cron jobs or special tools to be able to do it. I am also going to be experimenting with posting from mobile devices using the WordPress app.

PyOhio 2015 Talk on Smiley and Iterative Development

Yesterday I gave a talk titled “How I Built a Power Debugger Out of the Standard Library and Things I Found On the Internet” at
PyOhio 2015. The slides and video are now online.

Smiley demonstrates how to use Python’s native tracing capabilities to monitor not just what parts of your program run, but the data flowing through the program as it runs. All of the data is recorded for study after the program exits, which means you can pass different inputs and then compare the results of the runs. In this presentation, I will describe the evolution of Smiley, from concept through internal API changes as I worked on the implementation. I will also talk about tracing Python programs in general, and explain how the trace code in Smiley can be used to send trace data to different output
destinations.

Continue reading PyOhio 2015 Talk on Smiley and Iterative Development

Keyword Bookmarks for OpenStack Developers

As an OpenStack developer, I spend a lot of time looking at web sites for code review, project status, bug reports, the wiki, and other online collaboration tools. As a productivity boost, I’ve set up “keyword bookmarks” for all of the most commonly accessed tools, turning my browser’s input field into a command-line-like short-cut to jump directly to the page I want, without hunting around in a long list of links.

Continue reading Keyword Bookmarks for OpenStack Developers

virtualenvwrapper 4.6.0 – Enhancements to virtualenv

What is virtualenvwrapper?

virtualenvwrapper is a set of extensions to virtualenv. The
extensions include wrappers for creating and deleting virtual
environments and otherwise managing your development workflow, making
it easier to work on more than one project at a time without
introducing conflicts in their dependencies.

What’s New?

  • Fix an issue with links in the documentation. Contributed by
    Justin Abrahms (justinabrahms).
  • Fix an issue with lsvirtualenv reporting an error at the end of
    its output. Contributed by Robson
    Peixoto (robsonpeixoto).
  • Officially support python 3.4. Test and doc updates contributed by
    Jessamyn Smith (jessamynsmith).

Installing

Visit the virtualenvwrapper project page for download links and
installation instructions.

sphinxcontrib-paverutils 1.9.0 – Sphinx/Paver integration

sphinxcontrib-paverutils provides an alternative integration of
Sphinx and Paver. It supports calling Sphinx from within Paver using
multiple configurations, and does not assume you only want to build
HTML output.

What’s New?

  • Add the ability to pass extra configuration arguments through to
    Sphinx (contributed by papousek).

OpenStack Server Version Numbering

Last week the OpenStack community held our summit to discuss the work
we will be doing during the “Liberty” release cycle over the next six
months. On Friday, several of us met to discuss how we should specify
versions for the server projects. Unlike the other sessions where
there are etherpads for notes, we used a whiteboard and took
pictures. This post includes the picture, along with a transcription
of the text.

Snapshot

http://doughellmann.com/blog/wp-content/uploads/2015/05/IMG_2207.png

Transcription

Current

2015.1.0 -> All “servers” but Swift
2.3.0 -> Swift (“marketing-loaded” semver)
1.3.0
3.1.0 -> libraries (semver)
2.5.2 /

Option 1

Switch everything to semver

Cons

  • Distros need to specify an epoch
  • Pain to translate series to version

Option 2

Evolve yearly format

2015.1.0 -> 2016.
3000?
no 2015.2

Cons

  • Not sure how this would actually work

Agreed

Option 1, using semver.

Start with the next version 12, since Kilo was release 11.

Distros should use the epoch 1 (or the next higher value, if they
already have an epoch assigned) so these new version numbers sort
after the current releases.

OpenStack Requirements Handling, a.k.a. “Unbreak the World”

Last week the OpenStack community held our summit to discuss the work
we will be doing during the “Liberty” release cycle over the next six
months. On Friday, several of us met to discuss how we manage
dependencies. Unlike the other sessions where there are etherpads for
notes, we used a whiteboard and took pictures. This post includes
those pictures, along with transcriptions of the text.

Goals

We started by discussing the goals for requirements management, so we
could evaluate the proposal against those needs.

/blog/wp-content/uploads/2015/05/IMG_2202.png

  1. “Some” expression to downstream packagers/users
  2. Configure test jobs (unit, integration, & functional) (devstack &
    non-devstack)
  3. Encourage convergence/maintain co-installability
  4. Not be fiction
  5. pip install python-novaclient works
  6. Stop breaking all the time (esp. stable)
  7. Don’t make library release management painful
  • Current solution breaks 4 and 6 (and sometimes 5)
  • Robert’s solution breaks ?

Proposal

Next, Robert Collins presented his proposed solution for using
separate constraint lists for installing packages to be used in test
jobs, separate from the dependency specifications listed in each
project’s metadata.

/blog/wp-content/uploads/2015/05/IMG_2203.png

  • Global set(s) of complete consistent constraints
    • using == and exclusions
    • upper and lower
  • alternative testing
  • per project
    • excludes
    • minimums
    • semver upper
  • exclusions sync

Requirements specifications grow wider from left to right:

test sets (high/low) => coordinated => libraries/stackforge

! No guarantee that oslo releases won’t break project unit tests
(affirmative testing only runs integration tests)

TODO List

We prepared a list of actions we need to take this cycle to implement
the plan, and assigned each one to someone in the group.

/blog/wp-content/uploads/2015/05/IMG_2204.png

  • fix install requires in master+stable/kilo in each project (RC)
  • teach pip to honor constraints (RC)
  • change update.py to enforce wider range (until pip resolver exists)
    (RC)
  • initial global constraints for master + kilo (RC)
  • devstack patch to optionally use constraints (RC)
  • exp jobs to use constraints triggered by g-r (fungi)
  • Exp jobs triggered by local changes (fungi)
  • periodic job propose changes form pypi to master (RC)
  • unit test patch to use requirements
  • lower bounds test jobs

(I’m not sure what “exp jobs” are and may be mis-reading that)

Stable Branch Process

Then we reviewed the stable branch creation process to understand how
the change in requirements management will affect it.

pass 1

/blog/wp-content/uploads/2015/05/IMG_2205.png

Turn on master=>stable cross-check job
Release Oslo libraries
Freeze global requirements
Branch projects one at a time
Branch global requirements
Disable cross-check job
Unfreeze global-requirements

pass 2, with timeline

http://doughellmann.com/blog/wp-content/uploads/2015/05/IMG_2206.png

master/stable check
release oslo (FF-1)
converge constraints
l3/ff (soft requirements freeze) (FF)
hard freeze
branch projects (RC1)
branch g-r
disable cross-check
unfreeze

Conclusions

We finished with a little time to enjoy the beautiful scenery in
Vancouver.

/blog/wp-content/uploads/2015/05/IMG_2208.png