I hope this is the right sub-board for this. I'm ripping my hair out over this one and hope someone's already been here with this. We do a DVD-based distribution which includes the latest Blender 2.6.5 and it depends on lang/Python33 which is what's giving me fits. Because our DVD is a "read-only filesystem," Python is throwing fits over "OSError 30" for which I've found a way to code around it by handling the exception in _bootstrap.py which even their latest source does not handle. I've already resolved their errors with various other functions, I'm now down to solving one in their
portion of their mess which calls a TMP location with RW permissions and then tries to atomically move it elsewhere. That ain't going to be allowed to happen in our design.
Unlike earlier versions of Python however, _bootstrap.py is assembled into "<frozen importlib._bootstrap>" which is contained in a packed header file called "importlib.h" ... and when I change the source for _bootstrap.py, none of those changes apply leaving me with the recurring error of course. I've done the
No matter what however, the final build still contains the code from the buggy original source. Further investigation has determined that the importlib.h continues to be the original rather than a new importlib.h containing the changes, resulting in the "frozen" version still containing the buggy code which I've been trying to replace with exception handling for the RO filesystem that the final will be running on. On a RW system, all is well of course since apparently the Python folks never considered what I am doing to be an expected use of Python. Versions prior to 3.3 had no issues, I've been doing this for years until 3.3 threw this wrench in the works.
According to the notes in _bootstrap.py is this warning which tells me that my outcome here is an expected result:
So my question to anyone who knows their snakes is how do I go about making this happen? The documentation is vague, I see that the make script does not call the "freeze" despite my overwriting the original source for _bootstrap.py hours, or even days later in hopes that the Makefile will "freeze" the changed code into that "importlib.h" file so we can all go on our merry way and so there has to be something I'm missing, or is absent from the makefile which is causing the changes not to be reflected in the compiled code. I'm an old ANSI C guy, and don't normally play with ASP's ever since I left Billy world years ago, and so pythons are right out too. I'm sure this is an easy question for any experienced snake charmer, but I lack the proper tattoos I s'pose.
I'm going Indiana Jones here. "Snakes ... why does it always have to be snakes?" My head hurts!
Edit: ... and yes, I've tried running make again after completion, which is why I tried the clean and redo several times.
Code:
write_atomic(path, data, mode=0o666)Unlike earlier versions of Python however, _bootstrap.py is assembled into "<frozen importlib._bootstrap>" which is contained in a packed header file called "importlib.h" ... and when I change the source for _bootstrap.py, none of those changes apply leaving me with the recurring error of course. I've done the
$ make deinstall, $ make clean, ... overwrite the existing _bootstrap.py with the patched version I created and then perform the $ make install.No matter what however, the final build still contains the code from the buggy original source. Further investigation has determined that the importlib.h continues to be the original rather than a new importlib.h containing the changes, resulting in the "frozen" version still containing the buggy code which I've been trying to replace with exception handling for the RO filesystem that the final will be running on. On a RW system, all is well of course since apparently the Python folks never considered what I am doing to be an expected use of Python. Versions prior to 3.3 had no issues, I've been doing this for years until 3.3 threw this wrench in the works.
According to the notes in _bootstrap.py is this warning which tells me that my outcome here is an expected result:
Code:
"""Core implementation of import.
This module is NOT meant to be directly imported! It has been designed such
that it can be bootstrapped into Python as the implementation of import. As
such it requires the injection of specific modules and attributes in order to
work. One should use importlib as the public-facing version of this module.
"""
#
# IMPORTANT: Whenever making changes to this module, be sure to run
# a top-level make in order to get the frozen version of the module
# update. Not doing so, will result in the Makefile to fail for
# all others who don't have a ./python around to freeze the module
# in the early stages of compilation.
#
# See importlib._setup() for what is injected into the global namespace.
# When editing this code be aware that code executed at import time CANNOT
# reference any injected objects! This includes not only global code but also
# anything specified at the class level.
# XXX Make sure all public names have no single leading underscore and all
# others do.So my question to anyone who knows their snakes is how do I go about making this happen? The documentation is vague, I see that the make script does not call the "freeze" despite my overwriting the original source for _bootstrap.py hours, or even days later in hopes that the Makefile will "freeze" the changed code into that "importlib.h" file so we can all go on our merry way and so there has to be something I'm missing, or is absent from the makefile which is causing the changes not to be reflected in the compiled code. I'm an old ANSI C guy, and don't normally play with ASP's ever since I left Billy world years ago, and so pythons are right out too. I'm sure this is an easy question for any experienced snake charmer, but I lack the proper tattoos I s'pose.
I'm going Indiana Jones here. "Snakes ... why does it always have to be snakes?" My head hurts!
Edit: ... and yes, I've tried running make again after completion, which is why I tried the clean and redo several times.