Robust Python Packaging


  • cx freeze
  • symlinks
  • packaging

cx freeze

  • freezing critical tools that would break on upgrade
  • bigger rollback problem w/upgrades; solve that and it takes this one with it?
  • critical python apps to freeze?
    • release upgrader - how big will it be frozen?

  • wanted to get rid of symlink craziness
  • last cycle worked on implementation for multiple version of Python to exist (will be in Python 3.2)
  • ship 2.6 and 2.7? then backport PEP from 3.2
  • can we get some testing done that would, e.g., show us that there are too many issues with 2.7 (and thus not worry about it)
  • backport effort: implementation should be fairly straight-forward, however tests and documentation will be non-trivial; would be off by default, enabled by a switch. lookup uses the 3.2 rules (pycache first).

  • need to test universe
  • ACTION: mvo - add a auto upgrade test profile that installs all/most of the python (including universe) and tries to upgrade it and import all modules from 2.6, 2.7 (or whatever is available in maverick)
  • can't get rid of symlinks until extensions issue is addressed?
    • not touch symlinks at package installation time, but okay to ship them with a binary package


  • XXX

Python 3

  • keep python 2 and 3 stacks separate
  • get infrastructure into squeeze but modify packages in sq+1
  • okay to run 2to3 at build time only
  • keep source packages shared b/w 2 and 3 as long as we can, but split them if upstream stops shipping py2 versions


MaverickMeerkat/TechnicalOverview/Python/RobustPackaging (last edited 2010-10-14 18:41:54 by robbie.w)