startup.py and scripting.py Doubts

Question

Hello 🙂

I have two questions regarding the startup.py and the scripting.py:

1: As described in the docs, the startup.py common use is to load custom scripts on CE load (sys.path.append(), import); What is the common use case for the scripting.py ? What should I not do in either one?

2: I have created a startup.py on the workspace root (actually, it is a symbolic link) and I put some debugging "prints" to see if it worked. Upon CE loading, I see those messages written on the Console. However, when I open the Jython console, and try to access the modules imported inside the startup.py, it does not work. I'm forced to rewrite the code inside the startup.py file in order to access the desired functions... After reading the docs about the startup.py script, I got the impression this was one of its purposes. Can you help me here? Am I doing something wrong?

Thanks!
André

AndreasUlmer · Answer

I did a bit of testing and found the following behaviour:* scripting.py is not updated on CityEngine restart. Happens on all platforms. To trigger update, scripting.py and scripting$py.class need to be manually deleted from JythonCache. clearly a bug in CE 2011.2 (probably earlier versions as well)
* startup.py is reliably updated on CE startup.

I therefore recommend not to use a scripting.py file, but work with startup.py only instead.

RobertHexter · Answer

"I'm forced to delete the "scripting.py", "startup.py" and associated *.class files to reset the scripting environments."

Can confirm that you have to manually remove these from the Cache and restart in order to use this system as this is not done automatically when the files change.

I am doing this on windows7x64.

AndréCardoso · Answer

Ok, I think I found out what was going on 🙂 and it was my fault :S

On the matter of my imports not working:
- startup.py makes CE do a "import startup"; if, inside your custom "startup.py", you do a "import fantastic_module", then on the python console you'll need to do something like:
>>> startup.fantastic_module.foo()

to call your functions. 
And my problem was that I simply was not starting my call with "startup.", instead I was trying to access the modules directly.... My fault!
I think Andreas Ulmer tried to explain this to me on the first post 😄 but I did not quite get at the time!

- on the other hand, if you create a "scripting.py" inside the workspace root, their contents are copied to the CE own initialization script; So, if inside "scripting.py" you do a "import fantastic_module", then on the console you'll need to something like:
>>> fantastic_module.foo()

So, sorry for the entropy caused here :S

****

Nevertheless, I was able replicate the behaviour concerning the cache, on linux:
- when I delete the startup or scripting file from the workspace, they continue to exist in cache. I'm forced to delete the "scripting.py", "startup.py" and associated *.class files to reset the scripting environments.