Re: [Pythonmac-SIG] py2app and Django

[Ronald Oussoren]

On Aug 4, 2006, at 5:47 AM, Rob Hudson wrote:


(My apologies if this starts a new thread -- I'm posting from a
different mailing address and don't have the original email to  
reply to)



Django can not be packaged normally because it has in-package data
files. It won't work with either py2exe or py2app without tweaking.


Can you point me to or help me understand what in-package data  
files are

and why this affects it?


The exception you're getting:

   File "django/db/__init__.pyc", line 18, in ?
OSError: [Errno 20] Not a directory: '/Users/rhudson/Desktop/
Django-0.95/dist/run.app/Contents/Resources/lib/python2.3/site-
packages.zip/django/db/backends'

This indicates that some part of django tries to do a directory  
listing of the directory containing django.db.backends. This can mean  
two things: one is that there are data files in that directory  
(configuration data, images, ...), the other is that some setup code  
tries to locate all modules in that package.


With py2app and py2exe python code isn't stored directly in the  
filesystem but in zipfiles. Any code that tries to access the  
location where python code as if it were the filesystem will  
therefore fail.


Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] py2app and Django

[Rob Hudson]

(My apologies if this starts a new thread -- I'm posting from a 
different mailing address and don't have the original email to reply to)

 > Django can not be packaged normally because it has in-package data
 > files. It won't work with either py2exe or py2app without tweaking.

Can you point me to or help me understand what in-package data files are 
and why this affects it?

 > It may Just Work (or come close to that) with the --packages option.
 > It will definitely not work using any number of --includes options,
 > because that's not the issue.

OK.  I'll start experimenting with the --packages option.

I feel like I've started to make significant progress.  I've got a lot 
of the Django stack up and running but it looks like it is failing at 
getting some core parts of the database pieces loaded.  I've been 
posting my progress on the Django mailing list here:
http://groups.google.com/group/django-users/browse_thread/thread/609f539387ba8296

Thanks for the response.

-Rob


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app and Django

[Bob Ippolito]

On Aug 2, 2006, at 1:43 PM, Rob Hudson wrote:

> I'm trying to bundle up a Django built website.  Using SQLite and
> Django's built-in WSGI webserver, my thinking was that this would be
> 100% Python and would be straight forward to use py2app or py2exe  
> on it.
>
> I'm not familiar enough with py2app to know whether the error I'm
> getting is related to py2app or related to Django.  So I thought I'd
> post what I've done so far here for the list's guidance...
>
> I've followed the guide located here:
> http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html

Django can not be packaged normally because it has in-package data  
files. It won't work with either py2exe or py2app without tweaking.

It may Just Work (or come close to that) with the --packages option.  
It will definitely not work using any number of --includes options,  
because that's not the issue.

--packages is not applicable to py2exe though. In that case, you'll  
need to place the django package next to your .exe and --exclude it  
so that it doesn't get picked up in the zip.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] py2app and Django

[Rob Hudson]

Hello,

I'm trying to bundle up a Django built website.  Using SQLite and  
Django's built-in WSGI webserver, my thinking was that this would be  
100% Python and would be straight forward to use py2app or py2exe on it.

I'm not familiar enough with py2app to know whether the error I'm  
getting is related to py2app or related to Django.  So I thought I'd  
post what I've done so far here for the list's guidance...

I've followed the guide located here:
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html

My directory is basically a straight download of Django-0.95 with the  
addition of 2 files.  "run.py" which is my wrapper script to add  
Django to the Python path and kickstart the Django webserver.   
"py2app-setup.py" is named this way because Django already has a  
setup.py.  This may change once I figure out the details but for now  
this is what I've done.

===
run.py:
===
#!/usr/bin/env python
import sys, os
sys.path.append(os.getcwd())

from Quotes.manage import *
# We can also pass in host:port info to start server on.
# Possibly add checks to see if port is open already and increment to  
next one
# for the case of >1 app running simultaneously.
execute_manager(settings, ['','runserver'])

# NOTE: execute_manager takes over script control.  If we want to  
fire up a
# browser window we need to do that in another thread.
# Now that server is running, open web browser?
#import webbrowser
#webbrowser.open_new('http://localhost:8000')


py2app-setup.py:

#!/usr/bin/env python
from setuptools import setup
setup(
 app=["run.py"],
 setup_requires=["py2app"],
)

Also, "Quotes" is my dummy Django project and is a subdirectory under  
the Django-0.95 distribution.

I run this command and include a few Django modules:
python py2app-setup.py py2app -- 
includes=django.contrib.auth,django.contrib.sessions,django.contrib.site 
s

When I run the resulting "run.app" from the command line, this is the  
error I get:
# ./dist/run.app/Contents/MacOS/run
Validating models...
Unhandled exception in thread started by 
Traceback (most recent call last):
   File "django/core/management.pyc", line 1039, in inner_run
   File "django/core/management.pyc", line 1003, in validate
   File "django/core/management.pyc", line 815, in get_validation_errors
   File "django/db/__init__.pyc", line 18, in ?
OSError: [Errno 20] Not a directory: '/Users/rhudson/Desktop/ 
Django-0.95/dist/run.app/Contents/Resources/lib/python2.3/site- 
packages.zip/django/db/backends'


As an aside, you may be asking why do I want to make a website an  
application.  I work for a company that builds health based education  
websites.  Since some projects are funded by grant money, the phase  
one project needs to be reviewed to determine if the project is  
worthy of phase two money.  The reviewers need to remain anonymous  
and we need to assume the reviewers do not have an internet  
connection.  Therefore, we have to take our product (a website) and  
bundle it on a CD.  This has led to many problems.  We currently have  
a working solution for PHP based websites.  Now, we are investigating  
Django as a new platform and I'm doing the initial testing on whether  
we can ship a Django website.

Thanks,
Rob
--
Rob Hudson <[EMAIL PROTECTED]>
Senior Programmer
Oregon Center for Applied Science
http://www.orcasinc.com



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] appscript questions

[Bob Ippolito]

On Aug 3, 2006, at 3:49 PM, Dethe Elza wrote:

> Ronald Oussoren wrote:
>
>>  On Aug 3, 2006, at 7:08 PM, has wrote:
>>> p.s. If anyone'd like to help me out a bit, I'd really like to get
>>> all the manuals into the standard Python documentation format  
>>> now. So
>>> if you're familiar with the tools and would like to have a go then
>>> let me know - it'd be much appreciated.
>>
>> Why do you want to do that?  You have to use special tools to convert
>> that to a useable format.
>
> And if you're trying to get docs into the standard library, those  
> folks
> are perfectly willing to take plaintext documentation and dress it  
> up in
> LaTeX themselves.

I really don't think that should be any immediate concern in the  
appscript case, I'd definitely be -1 on that. I don't think it would  
be a good idea to put more platform-specific stuff in Python, or to  
subject appscript and its dependencies to the same release schedule  
as Python itself. I'd like to see most of plat-mac get extricated  
from Python in the future, and move the cross-platform chunks like  
plistlib and applesingle to the standard library (or just separate  
projects).

A much better and more immediate plan would be to setuptools-ify  
appscript so that it's easy to build and install. That could be done  
and released in an hour (oh how I love "python setup.py register  
bdist_egg sdist upload -s").

-bob

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] appscript questions

[Dethe Elza]

Ronald Oussoren wrote:

>  On Aug 3, 2006, at 7:08 PM, has wrote:
>> p.s. If anyone'd like to help me out a bit, I'd really like to get
>> all the manuals into the standard Python documentation format now. So
>> if you're familiar with the tools and would like to have a go then
>> let me know - it'd be much appreciated.
> 
> Why do you want to do that?  You have to use special tools to convert 
> that to a useable format.

And if you're trying to get docs into the standard library, those folks 
are perfectly willing to take plaintext documentation and dress it up in 
LaTeX themselves.

--Dethe
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] appscript questions

[Ronald Oussoren]

On Aug 3, 2006, at 7:08 PM, has wrote:


Hi folks,

Getting appscript prepared for the next release (only a couple away
from beta now), and wondering if anyone has preferences on the
following:

1. If a local application quits while a script is using it, either
unexpectedly or because the client script sent a 'quit' command,
should appscript relaunch that application automatically the next
time it sends a command to it, or should the application stay quit
unless the client script deliberately restarts it (by sending a
'run'/'open'/'activate'/'launch' command)?

(Automatic restarts, which is what AppleScript does, are more
convenient. However, if an application quit unexpectedly you probably
want it to stay quit and have the script halt with an error the next
time it tries to interact. So I'm more inclined towards the latter,
but would like to know what others think.)


If AppleScript automaticly restarts applications at least some users  
will think that not restarting is bug.  OTOH if you automaticly  
restart an application its state might be different than the script  
expects, which could cause problems.


I'm not a heavy appscript user, so I can't really say that I care one  
way or the other.





2. I'm looking to downgrade, if not eliminate, the role of ASTS. It's
no longer needed for remote scripting (good, as there were issues
when running it on remote machines with multiple active users), and a
3x speedup in appscript's terminology retrieval and parsing times
mean it provides less of a performance benefit when scripting local
apps. Three options I see:


I'd drop ASTS if it isn't really needed. I use appscript without ASTS  
and the startup time has never really bothered me. If the new version  
starts up significantly faster I don't see a good reason for  
retaining ASTS.  I also like the "complete foolproof" part of not  
having ASTS :-)



p.s. If anyone'd like to help me out a bit, I'd really like to get
all the manuals into the standard Python documentation format now. So
if you're familiar with the tools and would like to have a go then
let me know - it'd be much appreciated.


Why do you want to do that?  You have to use special tools to convert  
that to a useable format.


Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] appscript questions

[Nicholas Riley]

On Thu, Aug 03, 2006 at 06:08:26PM +0100, has wrote:
> So I'm more inclined towards the latter, but would like to know what
> others think.)

I agree - if the app quits, it should stay quit.  Sometimes when I'm
trying to abort a script I quit an app that's being controlled, and to
see it relaunch over and over and over again... aaargh.

> - Do away with ASTS completely and always retrieve and parse  
> terminology on the fly (less efficient, especially when repeatedly  
> running short scripts, but completely foolproof).
> 
> - Move to some sort of file-based cache, either managed completely  
> manually (users can selectively create terminology files for those  
> applications they want to avoid a cold start on), or automatically  
> (appscript could store all parsed terminologies in, say, /tmp).

I'd say to do the first one, and if you get complaints, move to the
second one.  I got very confused about the role of ASTS in remote
scripting myself (you may remember an email I sent you that effect
:-), and at least in my case I don't use appscript for small scripts,
I use it primarily for faceless background apps, so it wouldn't
matter.

> 3. Should appscript's built-in help() use textwrap to automatically  
> wrap long lines to fit in a standard 80-column terminal window? Or is  
> it better to leave the terminal window to wrap them naturally (i.e.  
> users may prefer to resize terminal windows themselves to make text  
> easier to read)?

How about wrapping to the terminal width, whatever it happens to be?
That's what most other things do.  (You could always have a
'wrap=False' option to help(), if necessary.)

-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] appscript questions

[has]

Hi folks,

Getting appscript prepared for the next release (only a couple away  
from beta now), and wondering if anyone has preferences on the  
following:

1. If a local application quits while a script is using it, either  
unexpectedly or because the client script sent a 'quit' command,  
should appscript relaunch that application automatically the next  
time it sends a command to it, or should the application stay quit  
unless the client script deliberately restarts it (by sending a  
'run'/'open'/'activate'/'launch' command)?

(Automatic restarts, which is what AppleScript does, are more  
convenient. However, if an application quit unexpectedly you probably  
want it to stay quit and have the script halt with an error the next  
time it tries to interact. So I'm more inclined towards the latter,  
but would like to know what others think.)


2. I'm looking to downgrade, if not eliminate, the role of ASTS. It's  
no longer needed for remote scripting (good, as there were issues  
when running it on remote machines with multiple active users), and a  
3x speedup in appscript's terminology retrieval and parsing times  
mean it provides less of a performance benefit when scripting local  
apps. Three options I see:

-  Retain ASTS support as it's still the most convenient way to  
provide external caching (users pretty much just need to launch it,  
either manually or as a login item, and can then forget about it).

- Do away with ASTS completely and always retrieve and parse  
terminology on the fly (less efficient, especially when repeatedly  
running short scripts, but completely foolproof).

- Move to some sort of file-based cache, either managed completely  
manually (users can selectively create terminology files for those  
applications they want to avoid a cold start on), or automatically  
(appscript could store all parsed terminologies in, say, /tmp).


3. Should appscript's built-in help() use textwrap to automatically  
wrap long lines to fit in a standard 80-column terminal window? Or is  
it better to leave the terminal window to wrap them naturally (i.e.  
users may prefer to resize terminal windows themselves to make text  
easier to read)?


Thanks,

has

p.s. If anyone'd like to help me out a bit, I'd really like to get  
all the manuals into the standard Python documentation format now. So  
if you're familiar with the tools and would like to have a go then  
let me know - it'd be much appreciated.

-- 
http://freespace.virgin.net/hamish.sanderson/


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig