I know I'm coming in the middle of this, and I'm sure I don't understand all the issues yet, but I'll chime in here anyway. :)
On Jan 19, 2010, at 10:39 AM, Josselin Mouette wrote: >I’m also still wondering which exact problem this proposal is trying to >fix. Currently the only thing it does seem to address is a very specific >kind of issue that Loïc explained to me, which happens in Python-based >package managers: when you upgrade the Python packages the package >manager depends on, including a change in the default Python version (if >the default Python version doesn’t change, all modules remain available >during the upgrade, with both -central and -support), and the upgrade >process is interrupted, the package manager might not be able to >restart. There are other ways to fix this bug; the most obvious way >being to apply something similar to your proposal, but only to a very >small set of Python packages, namely those on which the package managers >depend. For the rest of the archive, I just don’t see the point. How many applications are affected by this kind of upgrade breakage? Have you considered cx_Freeze'ing them so they aren't subject to Python package breakage? cx_Freeze[1] is a tool that essentially creates a small binary executable, and zips all the dependent modules onto the end of the file. So the executable is actually a zip file, which Python can import from. The idea is that something like update-manager could be frozen so that it can run even if the modules it depends on have been uninstalled or otherwise broken. From what I understand, this doesn't solve all the problems in pycentral/pysupport, but it could solve an important subset of the problems being experienced during upgrades. -Barry [1] http://cx-freeze.sourceforge.net/
signature.asc
Description: PGP signature
