On Sat, May 5, 2012 at 6:49 AM, Carl Meyer <c...@oddbird.net> wrote: > 1) Document it and provide a tool for easily upgrading a venv in this > situation. This may be adequate. In practice the situation is quite rare: > 2.6.8/2.7.3 is the only actual example in the history of virtualenv that I'm > aware of. The disadvantage is that if the problem does occur, the error will > probably be quite confusing and seemingly unrelated to pyvenv.
I think this is the way to go, for basically the same reasons that we did it this way this time: there's no good reason to pay an ongoing cost to further mitigate the risks associated with an already incredibly rare event. It would become part of the standard venv debugging toolkit: Q X.1: Does the problem only occur inside a particular virtual environment? Q X.2: If yes, did you recently upgrade the system Python to a new point release? Q X.3: If yes, did you run <command that updates the Python binary copy in the virtual environment>? Q X.4: If no, do so and see if the problem goes away. Even if it still doesn't work, at least you've eliminated this particular error as a possible cause. Personally, I expect that "always update your virtual environment binaries after updating the system Python to a new point release" will itself become a recommended practice when using virtual environments. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
