Roundup Tracker - Issues

Issue 724714

classification
roundup programs leave compiled files in cwd
Type: Severity: normal
Components: None Versions:
process
Status: closed fixed
:
: : jlgijsbers, richard, rouilj
Priority: normal :

Created on 2003-04-20 19:46 by rouilj, last changed 2003-09-21 18:04 by rouilj.

Files
File name Uploaded Description Edit Remove
listing rouilj, 2003-04-22 13:22 ls -l of detectors directory.
Messages
msg763 Author: [hidden] (rouilj) Date: 2003-04-20 19:46
If I run a command line roundup program (like roundup-mailgw) or 
something else I wrote, it leaves compiled copies of the detectors 
in the current directory that I invoked the program from.

This 
seems broken and inefficient. Its recompiling new copies of the .py 
files into the current directory when
it has perfectly good copies 
in the directory where the .py files exist.

Is this a python 
issue, or is there some way the program
can load/compile 
modules and not get the proper cache
for the compiled 
modules?

-- rouilj
msg764 Author: [hidden] (richard) Date: 2003-04-20 22:25
Logged In: YES 
user_id=6405

I should be compiling the python modules when they're installed. 
 
msg765 Author: [hidden] (rouilj) Date: 2003-04-21 04:07
Logged In: YES 
user_id=707416

Richard:

I compiled the modules in the detectors directory.
I 
had *.pyc, *.pyo and both *.pyc and *.pyo and it
didn't matter, I still had 
the *.pyc file compiled into my cwd
if I ran with python, and *.pyo if I ran 
witrh python -O.

I saw the same thing when I had a link from 
/usr/lib/python2.2/site_packages/roundup
to the installed 
tree.

-- rouilj
msg766 Author: [hidden] (richard) Date: 2003-04-21 10:32
Logged In: YES 
user_id=6405

What are the timestamps for the files in the detectors dir? The 
pyc/pyo have to be younger than the py. If they are, then I'm very 
confused. 
 
msg767 Author: [hidden] (rouilj) Date: 2003-04-22 13:21
Logged In: YES 
user_id=707416

The full listing is attached, but here is an example.

-rw-r--r--    1 jrouilla 
Administ      792 Mar 11 16:28 enforceRepairRole.py
-rw-r--r--    1 jrouilla 
Administ     1075 Apr 21 00:01 enforceRepairRole.pyc
-rw-r--r--    1 jrouilla 
Administ     1030 Apr 21 00:02 enforceRepairRole.pyo

and when I 
run the roundup-action script, I get:

-rw-rw-r--    1 jrouilla Administ     1030 
Apr 22 09:18 enforceRepairRole.pyo

in the cwd. Also I get all the 
other .py files in the detector directory as .pyo files except the 
__init__.py file.

-- rouilj
msg768 Author: [hidden] (richard) Date: 2003-04-23 12:17
Logged In: YES 
user_id=6405

How strange... 
 
Looks like I'm going to have to re-subscribe to python-list to ask 
about this one... 
 
msg769 Author: [hidden] (rouilj) Date: 2003-06-21 18:43
Logged In: YES 
user_id=707416

Richard:

Did the python list come up with anything? This is starting
to be a problem when I am running multiple trackers from a 
single instance of roundup-server.

-- rouilj
msg770 Author: [hidden] (richard) Date: 2003-07-04 00:33
Logged In: YES 
user_id=6405

Still no joy here - I now have code in the install that pre-compiles 
the detectors, but when the instance is opened, the pyc files still 
appear in the "current directory". Hurm. 
 
msg771 Author: [hidden] (richard) Date: 2003-07-09 03:25
Logged In: YES 
user_id=6405

I should try cwd()'ing to the detectors dir before importing the 
detector modules...
msg772 Author: [hidden] (richard) Date: 2003-08-12 01:16
Logged In: YES 
user_id=6405

The whole process of tracker config loading needs to be 
revamped. I'm pushing that off until 0.7 because I *really* want 
to get 0.6 out the door...
msg773 Author: [hidden] (jlgijsbers) Date: 2003-09-15 19:22
Logged In: YES 
user_id=469548

Patch 800718 fixed this.
msg774 Author: [hidden] (rouilj) Date: 2003-09-20 18:37
Logged In: YES 
user_id=707416

Sorry. This isn't fixed for me. I am still seeing copies of the pyo files
for my detectors being left in the directory I started roundup-server from.

I run

   roundup-server -p 8080 -n 127.0.0.1 sysadmin=/var/roundup/sysadmin

from my home directory and I get:

-rw-rw-r--    1 jrouilla Administ     2125 Sep 20 14:31 blockedby.pyo
-rw-rw-r--    1 jrouilla Administ     6982 Sep 20 14:31 changeowner.pyo
-rw-rw-r--    1 jrouilla Administ     1069 Sep 20 14:31 checktransition.pyo
-rw-rw-r--    1 jrouilla Administ      769 Sep 20 14:31 default_priority.pyo
-rw-rw-r--    1 jrouilla Administ     4193 Sep 20 14:31 dependson_semantics.pyo
-rw-rw-r--    1 jrouilla Administ     1673 Sep 20 14:31 disjointdependsongroups.pyo
-rw-rw-r--    1 jrouilla Administ     1060 Sep 20 14:31 enforceRepairRole.pyo
-rw-rw-r--    1 jrouilla Administ     5286 Sep 20 14:31 group_semantics.pyo
-rw-rw-r--    1 jrouilla Administ     1773 Sep 20 14:31 needsreply.pyo
-rw-rw-r--    1 jrouilla Administ     1493 Sep 20 14:31 newissuecopy.pyo
-rw-rw-r--    1 jrouilla Administ     1601 Sep 20 14:31 nosy_keyword_auditor.pyo
-rw-rw-r--    1 jrouilla Administ     6043 Sep 20 14:31 nosyreaction.pyo
-rw-rw-r--    1 jrouilla Administ     1578 Sep 20 14:31 requestedby.pyo
-rw-rw-r--    1 jrouilla Administ     2175 Sep 20 14:31 statusauditor.pyo
-rw-rw-r--    1 jrouilla Administ     1412 Sep 20 14:31 statusperms.pyo
-rw-rw-r--    1 jrouilla Administ     1143 Sep 20 14:31 userauditor.pyo
-rw-rw-r--    1 jrouilla Administ     5624 Sep 20 14:31 verynosy.pyo

The detectors directory under /var/roundup/sysadmin/detectors looks like:

drwxr-xr-x+   2 jrouilla Administ        0 Aug 31 17:50 CVS/
-rw-r--r--    1 jrouilla Administ     4217 May 18 19:09 README
-rw-r--r--    1 jrouilla Administ     1524 Mar  7  2003 __init__.py
-rw-rw-r--    1 jrouilla Administ      938 Jul 27 13:29 __init__.pyc
-rw-rw-r--    1 jrouilla Administ      910 Sep 11 19:13 __init__.pyo
-r-xr-xr-x+   1 Administ ????????     1931 Jun 15 17:55 blockedby.py*
-rwxr-xr-x    1 jrouilla Administ     9982 May 18 16:22 changeowner.py*
-rw-rw-r--    1 jrouilla Administ     6932 May 24 21:14 changeowner.pyo
-rw-r--r--    1 jrouilla Administ     1027 Apr 20 00:59 checktransition.py
-rw-rw-r--    1 jrouilla Administ     1039 May 11 23:00 checktransition.pyo
-rw-r--r--    1 jrouilla Administ      674 Mar 10  2003 default_priority.py
-rw-rw-r--    1 jrouilla Administ      739 May 11 23:00 default_priority.pyo
-rwxrwxrwx    1 jrouilla Administ     5947 May 27 00:00 dependson_semantics.py*
-rw-rw-r--    1 jrouilla Administ     4153 May 11 23:00 dependson_semantics.pyo
-rw-r--r--    1 jrouilla Administ     2014 Mar 16  2003 disjointdependsongroups.py
-rw-rw-r--    1 jrouilla Administ     1643 May 11 23:00 disjointdependsongroups.pyo
...

This is under cygwin 1.5.4 windows 2000.

Where is patch 800718 described?

-- rouilj
msg775 Author: [hidden] (richard) Date: 2003-09-20 21:32
Logged In: YES 
user_id=6405

Sourceforge will break the URL, but here goes: 
 
https://sourceforge.net/tracker/index.php?func=detail&aid=800718&group_id=31577&atid=402790 
 
This patch definitely fixed the problem for me when I run the demo 
script. No idea why it wouldn't also fix it for you... 
 
msg776 Author: [hidden] (rouilj) Date: 2003-09-21 18:04
Logged In: YES 
user_id=707416

Now that I found the patch and applied it to the sysadmin
tracker, it works. For a final fix, I copied the 
detector/__init__.py file to the same location in my tracker.
I suspect it will work fine.

However in looking at the patch, I am confused a bit.
Why wouldn't this:

            fp = open(path)
            try:
                module = imp.load_module(name, open(path), 
path,
                    ('.py', 'r', imp.PY_SOURCE))

be written as:

            fp = open(path)
            try:
                module = imp.load_module(name, fp, path,
                    ('.py', 'r', imp.PY_SOURCE))

and save the second open call? Also the docs say that
the fp argument must be closed by the caller. Doesn't putting
an open(path) in the function call leave the file handle open,
or is it automatically closed because its assigned to a local 
(parameter) variable?

-- rouilj
History
Date User Action Args
2003-04-20 19:46:16rouiljcreate