Re: [Jython-dev] [Bug #122610] SecEx in MS applerviewer

[Samuele P. <pe...@in...>]

Hi.

> 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.


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.
 
regards