From: <bc...@wo...> - 2000-11-18 16:39:50
|
[me] >> A null frozenPackage parameter seems to occur when a module was compiled >> without the --deep option. My interpretation of the meaning of "frozen" >> and "--deep" goes like this: >> >> 1) Using --deep (which results in Py.frozen == true) we can assume >> a completely closed environment. Every external module and package >> have been found by the compiler so there should be no need to search >> the filesystem for anything. >> >> 2) Module that have been compile without the --deep option should be >> importable and runnable as if they were compiled by CodeCompiler. >> Such modules are compiled but they are not frozen. F.ex when running >> such a module directly it should attempt to build the cache/packages >> and should search the file system for modules and classes. >> >> The 2) type of compilation is not supported very well at the moment. The >> cache/packages dir is created, but no .jars are cached because jythonc >> passes these properties to runMain(): >> >> python.packages.paths = "" >> python.packages.directories = "" >> >> which creates a strange enviroment where java classes can't be found in >> submodules. >> >> Perhaps we should have an additional options to jythonc, say "--depend" >> which will track dependencies and compile all submodules but which does >> not set the Py.frozen flag. [Samuele] >So the bug is not really a bug. >When I removed the Py.frozen test in loadFromPath I was actually >thinking about 2). > >It seems to me that setting > > python.packages.paths = "" > python.packages.directories = "" > >is redudant. > >The right logic should be to avoid Py.frozen tests around >but to have in frozen code case (--deep): > > sys.path = [] > and the cache not initialized. > and PackageManager, frozenModules filled with the params to initProxy/ > runMain. Right. It would be a slight change of behavior for a frozen program that makes changes to sys.path, but I think that is acceptable. regards, finn |