Fanstatic Changelog

New in version 0.15

November 8th, 2012
  • Add "default" argument to Slot to specify a resource which will be filled in if there is no other resource specified in need(). Thanks to nilo.
  • Ensure published bundles carry the correct Content-Type header. Previously, all bundles were delivered with text/html. Thanks to David Beitey.

New in version 0.14 (October 30th, 2012)

  • Alex Grönholm added python3 and pypy support.
  • Using tox to test on python2.6/2.7/3.2/3.3/pypy.
  • Mirroring the bitbucket repo to github in order to run tests on travis-ci:!/fanstatic/fanstatic

New in version 0.13.3 (September 15th, 2012)

  • No longer use WebOb's wsgify decorator in both the injector and delegator middlewares, as it has issues handling parent application WSGI response (

New in version 0.13.2 (August 27th, 2012)

  • Fixed issue #78: "fanstatic.checksum.md5 is not guaranteed", thanks to takanao ENDOH.

New in version 0.13.1 (August 21st, 2012)

  • Fixed bug where mode resources created by string 'shortcut' didn't inherit the renderer, bundling, dependency parameters.

New in version 0.12 (August 6th, 2012)

  • Documentation fix in code samples, thanks to Toby Dacre.
  • Fix issue #74, minified .js not served in bottom unless force_bottom, thanks to Toby Dacre.
  • Cherry picked pull request #1 "support-wsgi-apps-not-mounted-at-/", thanks to Éric Lemoine.
  • Add print css renderer.

New in version 0.11.4 (January 17th, 2012)

  • There was another bug with ordering resources when multiple libraries were involved. This time the way library_nr was calculated was changed so that it wouldn't happen anymore.
  • The intent of library_nr was to have it always be 1 higher than the maximum library_nr of any libraries this library is based on.
  • In practice this wouldn't always happen, because each resource had its own library_nr. In some circumstances the resources in libraries depending on other libraries would consistently get a library_nr too low, as each resource they were based on had a library_nr that was too low as well, even though another resource could exist in that library with a higher library_nr. This could cause the library_nr of all resources in a library to be too low.
  • This is now fixed to moving library_nr to the place it should've maintained on in the first place: the library itself. It is calculated now once per library, just before the resources are sorted for the first time during the application's run. Since by the time resources need to be sorted all resources are known, the library_nr can be calculated correctly.

New in version 0.11.3 (November 14th, 2011)

  • There was a bug with ordering resources when multiple libraries are involved:

New in version 0.11.2 (May 19th, 2011)

  • Update the docs for