Your example did work. The problem I'm having is the sub-modules in
the namespace packages. Here is what I'm observing. If I put my
custom namespace in the namespace packages list ('wind'), then the
build has a wind directory with a server and model subdirectory
inside. This is as it should be. These sub-directories are empty,
however. I'm finding that they can be populated by explicitly
importing each module in my top level script that is being frozen.
My wind.server package looks like:
wind
server
models
my_model.py
views
my_view.py
...
...
(plus about 15 more python files in this dir).
So I can make it work by importing all the modules from the views
directory. Is this the expected behavior? It is not that big of a
deal to have to do, but it would be nice if I just specifying the
'wind' namespace would take care of all that.
I'm very happy with your fixes for this, by the way. My current
situation is ten times better than where I stood a couple of days
ago. Now it looks very possible I'll be able to deploy this app with
its crazy dependencies.
Craig
On Feb 24, 2010, at 11:09 AM, Anthony Tuininga wrote:
> On Wed, Feb 24, 2010 at 10:31 AM, Craig Swank <[email protected]>
> wrote:
>> Ok, now the repoze and zope packages appear to all be going into the
>> build. When I add my custom namespace packages they don't go in.
>> Can
>> you try it out with the two 'rubbish' packages I made? I tried these
>> and they also didn't work. My library directory of the build has a
>> 'rubbish' folder, but it only has an __init__.py file. If you can
>> get
>> them to work, could you please show me your setup.py?
>
> Sure. They do indeed work.
>
> This is my setup.py
>
> from cx_Freeze import setup, Executable
>
> buildOptions = dict(
> namespace_packages = ["rubbish"])
> setup(
> name = "test_freeze",
> version = "0.1",
> description = "Sample cx_Freeze script",
> options = dict(build_exe = buildOptions),
> executables = [Executable("test_freeze.py")])
>
> And this is my test_freeze.py
>
> import rubbish.example
> import rubbish.anotherexample
>
> print "Rubbish.example", rubbish.example
> print "Rubbish.anotherexample", rubbish.anotherexample
>
> Note the use of the top-level package which has been broken up. I
> assume you had specified "rubbish.example" and
> "rubbish.anotherexample" in your namespace package list, right? I
> suspect that will be a common "error" so what I have just checked in
> is code to ensure that if a subsidiary package is marked as a
> namespace package so are all of its parents, which must by definition
> be true. Let me know how that goes, now. Thanks!
>
> Anthony
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> cx-freeze-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cx-freeze-users
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
cx-freeze-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cx-freeze-users
