|
From: Titus B. <ti...@ca...> - 2001-11-28 19:11:00
|
Hi all,
I have an odd situation. Imagine the following setup:
test1.py
test2.py
source/test3.py
where test1.py contains:
-- test1.py
import test2, sys
sys.path.append('source/')
import test3
--
This works fine with 'jython test1.py'. It works fine if I do
'jythonc --all -j out.jar test1.py test2.py source/test3.py', move out.jar
to another directory, put it in the classpath, and type 'import test1' into
jython.
However, it does not work if I do
'jythonc --all -j out.jar test1.py'
It finds the test2 dependency, but not the test3 dependency.
Even odder is that in one of my projects -- the only one for which I can
make a simple distribution -- 'jythonc --all -j out.jar start.py' includes
all of the files upon which start.py is dependent.
I can't figure out what makes some things work and others not; are there any
hints that anyone can give me? (I'd compile jython myself and just put
printlns in, but I can't compile it at the moment.)
tnx,
--titus
|
|
From: Samuele P. <ped...@bl...> - 2001-11-28 19:36:35
|
Please add a print statement to your test1.py,
and try again with your experiments.
You will be even more disillusioned
but it will make for a more coherent report ;).
regards.
> Hi all,
>
> I have an odd situation. Imagine the following setup:
>
> test1.py
> test2.py
> source/test3.py
>
> where test1.py contains:
>
> -- test1.py
>
> import test2, sys
> sys.path.append('source/')
> import test3
>
> --
>
> This works fine with 'jython test1.py'. It works fine if I do
>
> 'jythonc --all -j out.jar test1.py test2.py source/test3.py', move out.jar
> to another directory, put it in the classpath, and type 'import test1' into
> jython.
>
> However, it does not work if I do
>
> 'jythonc --all -j out.jar test1.py'
>
> It finds the test2 dependency, but not the test3 dependency.
>
> Even odder is that in one of my projects -- the only one for which I can
> make a simple distribution -- 'jythonc --all -j out.jar start.py' includes
> all of the files upon which start.py is dependent.
>
> I can't figure out what makes some things work and others not; are there any
> hints that anyone can give me? (I'd compile jython myself and just put
> printlns in, but I can't compile it at the moment.)
>
> tnx,
> --titus
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Titus B. <ti...@ca...> - 2001-11-28 20:30:18
|
-> Please add a print statement to your test1.py, -> and try again with your experiments. -> -> You will be even more disillusioned -> but it will make for a more coherent report ;). Yeah, I've done that, too... but it wasn't relevant to the jythonc report ;). What Samuele is referring to: --- test4.py print 'hi' --- 'jython test4.py' will produce 'hi' 'jythonc -j out.jar test4.py' followed by an 'import test4' in jython with out.jar in the classpath will produce nothing, you have to do import test4 test4.main([]) Nonetheless, I don't see this as a problem related to my first set of questions -- is it? --t |
|
From: Samuele P. <ped...@bl...> - 2001-11-28 21:14:40
|
[Titus Brown] > -> Please add a print statement to your test1.py, > -> and try again with your experiments. > -> > -> You will be even more disillusioned > -> but it will make for a more coherent report ;). > > Yeah, I've done that, too... but it wasn't relevant to the jythonc report ;). > > What Samuele is referring to: > > --- test4.py > print 'hi' > --- > > 'jython test4.py' will produce 'hi' > > 'jythonc -j out.jar test4.py' followed by an 'import test4' in jython with > out.jar in the classpath will produce nothing, you have to do > > import test4 > test4.main([]) > > Nonetheless, I don't see this as a problem related to my first set of > questions -- is it? > It seems not, but sorry and better so, I was confused by your report, you are not :) > I can't figure out what makes some things work and others not; are there any > hints that anyone can give me? (I'd compile jython myself and just put > printlns in, but I can't compile it at the moment.) The answer: don't expect jythonc to cope properly with program-driven changes to sys.path and similar dynamic stuff. jythonc is a *static* tool. regards. |
|
From: Titus B. <ti...@ca...> - 2001-11-28 21:33:05
|
-> > Nonetheless, I don't see this as a problem related to my first set of -> > questions -- is it? -> > -> -> It seems not, but sorry and better so, I was confused by your report, you are -> not :) -> -> > I can't figure out what makes some things work and others not; are there any -> > hints that anyone can give me? (I'd compile jython myself and just put -> > printlns in, but I can't compile it at the moment.) -> -> The answer: don't expect jythonc to cope properly with program-driven -> changes to sys.path and similar dynamic stuff. -> -> jythonc is a *static* tool. Ahh, but I have contraindications! In a more complicated piece of code, dynamic modifications to sys.path result in jythonc finding and correctly compiling (and including in the output .jar) files from other directories that were specified only in sys.path. So, if no dynamic modifications to sys.path should work for jythonc, then I don't understand why it *does* work occasionally; and if dynamic modifications *should* work, then I don't understand why it *isn't* for other projects. If anyone wants to take a look to see what I mean, check out the latest version of FamilyRelations: cvs -d:pserver:ano...@cv...:/cvsroot/familyjewels login cvs -d:pserver:ano...@cv...:/cvsroot/familyjewels co FamilyRelations and do cd FamilyRelations && make (you may need to modify the separator from : to ; in some of the classpaths). This works. It's worked for a long time. I don't understand why doing what is as far as I can tell the same sort of thing isn't working now! But I gather that if there is a bug, it's not a well known one ;). cheers, --titus |
|
From: Samuele P. <ped...@bl...> - 2001-11-28 23:07:47
|
[Titus Brown]
> -> The answer: don't expect jythonc to cope properly with program-driven
> -> changes to sys.path and similar dynamic stuff.
> ->
> -> jythonc is a *static* tool.
>
> Ahh, but I have contraindications! In a more complicated piece of code,
> dynamic modifications to sys.path result in jythonc finding and correctly
> compiling (and including in the output .jar) files from other directories
> that were specified only in sys.path.
>
> So, if no dynamic modifications to sys.path should work for jythonc, then I
> don't understand why it *does* work occasionally; and if dynamic
modifications
> *should* work, then I don't understand why it *isn't* for other projects.
>
[snip]
> But I gather that if there is a bug, it's not a well known one ;).
>
First I insist:
The answer: don't expect jythonc to cope properly with program-driven
changes to sys.path and similar dynamic stuff.
jythonc is a *static* tool.
Then consider:
<source/test3.py>
</source/test3.py>
<test2.py>
print "test2 says hi!"
import sys
sys.path.append('source/')
import test3
blackmagic = 1
</test2.py>
***** Nothing happens **
<test1.py>
import test2
</test1.py>
Let's go:
>jythonc --deep -j out.jar test1.py
processing test1
processing test2
Required packages:
Creating adapters:
Creating .java files:
test2 module
test1 module
Compiling .java to .class...
Compiling with args: <...>
0
Building archive: out.jar
Tracking java dependencies:
***** Blackmagic **
<test1.py>
from test2 import blackmagic
</test1.py>
Let's play sorcerer's apprentice:
>jythonc --deep -j out.jar test1.py
processing test1
test2 says hi!
processing test2
processing test3
Required packages:
Creating adapters:
Creating .java files:
test2 module
test3 module
test1 module
Compiling .java to .class...
Compiling with args: <...>
0
Building archive: out.jar
Tracking java dependencies:
***** So **
indeed I was able to reproduce what you are reporting.
You can report this as a bug, anyway what you
describe as things working is just an unwanted side-effect
of an hackish implementation that sometimes *do*
an import to deal with (some flavor of) import.
No, sys.path dynamic modification is not intended to
be supported by jythonc.
Please don't understimate our understanding
of the amount of evil lurking inside jythonc :)
That's all folk, Samuele Pedroni.
|
|
From: Samuele P. <ped...@bl...> - 2001-11-28 23:31:16
|
[me] > You can report this as a bug, anyway what you > describe as things working is just an unwanted side-effect > of an hackish implementation that sometimes *do* > an import to deal with (some flavor of) import. An implementation not about to change that soon, to be precise ;) regards, Samuele Pedroni. |
|
From: Titus B. <ti...@ca...> - 2001-11-28 23:40:24
|
[ munch ] -> ***** So ** -> -> indeed I was able to reproduce what you are reporting. -> -> You can report this as a bug, anyway what you -> describe as things working is just an unwanted side-effect -> of an hackish implementation that sometimes *do* -> an import to deal with (some flavor of) import. -> -> No, sys.path dynamic modification is not intended to -> be supported by jythonc. -> -> Please don't understimate our understanding -> of the amount of evil lurking inside jythonc :) That's ... just ......... EVIL. Thanks for the explanation; now I understand how to manipulate jythonc into doing what I want it to do, at least... ;) --titus |