I think these changes came about due to this thread:
http://www.mail-archive.com/[email protected]/msg08794.html where
there was an issue w/ relative paths and starting an app.
And you may have found the root of the problem but you didn't quote the code
change. There's these additional lines:
gen.EmitCall(OpCodes.Call,
clr.GetClrType(System.IO.DirectoryInfo).GetMethod("get_FullName"), ())
gen.EmitCall(OpCodes.Call,
clr.GetClrType(System.Environment).GetMethod("set_CurrentDirectory"), ())
which might be causing the problem as we change the CWD before we really kick
things off. Does replacing the set_CurrentDirectory line in pyc.py with:
gen.EmitCall(OpCodes.Pop)
possibly fix things for you (that'll make that a NOP but should leave all the
other changes in place)?
From: [email protected]
[mailto:[email protected]] On Behalf Of Ken MacDonald
Sent: Wednesday, October 06, 2010 1:26 PM
To: Discussion of IronPython
Subject: Re: [IronPython] change in standard library behavior for compiled
.exe/.dll???
As an FYI, the following change was made from the IP 2.6 version of pyc.py to
the IP 2.7 version (newer version shown first):
< # get the ScriptCode assembly...
< gen.EmitCall(OpCodes.Call,
clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ())
< gen.EmitCall(OpCodes.Callvirt,
clr.GetClrType(Assembly).GetMethod("get_Location"), ())
---
> # get the ScriptCode assembly...
> gen.EmitCall(OpCodes.Call,
> clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ());
> gen.EmitCall(OpCodes.Call,
> clr.GetClrType(Assembly).GetMethod("get_CodeBase"), ());
> gen.Emit(OpCodes.Newobj, clr.GetClrType(System.Uri).GetConstructor( (str,
> ) ));
> gen.EmitCall(OpCodes.Call,
> clr.GetClrType(System.Uri).GetMethod("get_LocalPath"), ());
Don't know what these things do at this point, but wondering if the changes
have to do with compiling the entire code tree into the application .DLL???
Ken
On Wed, Oct 6, 2010 at 4:04 PM, Ken MacDonald
<[email protected]<mailto:[email protected]>> wrote:
Hi Dino,
On Wed, Oct 6, 2010 at 2:57 PM, Dino Viehland
<[email protected]<mailto:[email protected]>> wrote:
How are you distributing your app? I'm assuming you're going to have something
like:
MyApp\
MyApp.exe
MyApp.dll
IronPython.dll
IronPython.Modules.DLL
...
This is exactly how we have been distributing our app up to IP 2.6 with .NET
3.5. We also have another DLL with our resources in it; XAML, icons, image
files, but no code per se. We have been distributing it this way to customer
systems that do NOT have IronPython installed, or any sign of the std. library,
or "os.py" specifically, and it's been working really, really well.
We're trying to understand what changed moving to IP 2.7 and .NET 4.0 that we
should have to care about distributing the std. library now. The way it was
before was quite simple and robust; deliver a small handful of files and it
just worked, very easy to keep track of. Now instead of distributing 5 files,
we suddenly need to distribute 500??? We've figured out that it certainly COULD
work as described below, but it seems like a giant step backwards on several
fronts, including the potential for folks to maliciously or accidentally tamper
with the std lib. sources and affect the functioning of our app. So, how do we
get back to the old/better functionality?
On a slightly related note, our app imports some package directories in
addition, e.g. "import ctypes". When python encounters a directory import, it
looks for __init__.py in the directory, and derives the package import
directions from there, as I understand it. However, I can't specify the
"ctypes" directory as an argument to the pyc.py compile app; just causes it to
croak. If I explicitly specified paths like "lib\ctypes\__init__.py" and the
other files in the ctypes subdirectory, it seems like "import ctypes" would
have no clue that the __init__.py that was compiled in had anything to do with
the "ctypes" package, as the path names are presumably irrelevant to the
compiler as long as they specify a python file. I'm considering mod'ing pyc.py
to be able to incorporate a list of std lib modules to compile in: simple
enough for the standalone files like "os.py", but the compile modules don't
seem to be able to grok what to do with a package subdirectory.
Ken
You should be able to also distribute the standard library and just drop it
into a Lib directory next to IronPython.dll:
MyApp\
MyApp.exe
MyApp.dll
IronPython.dll
IronPython.Modules.DLL
...
Lib\
os.py
That lib dir should be on sys.path at startup and so it should be available for
importing.
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Ken MacDonald
Sent: Wednesday, October 06, 2010 11:42 AM
To: Michael Foord
Cc: Discussion of IronPython
Subject: Re: [IronPython] change in standard library behavior for compiled
.exe/.dll???
Hi Michael,
I started out on implementing this, but I am importing maybe a dozen of the
std. library modules, which then import others, and so on. It appears that
eventually, most of the std modules would have to be imported explicitly
(perhaps 400 or so files) which might make for a somewhat cumbersome command
line, incidentally also about 20K characters too long :-). I'm hoping to find a
way to get this to work as well as it did under IP 2.5 / .NET 3.5.
Noah: what kind of problems are YOU having with pyc.py under 4.0? Maybe one of
us can suggest something if we have an understanding of what you're trying to
do.
Ken
On Wed, Oct 6, 2010 at 7:08 AM, Michael Foord
<[email protected]<mailto:[email protected]>> wrote:
On 05/10/2010 22:27, Ken MacDonald wrote:
I've been looking at the .exe's we built - using pyc.py - with IP 2.5/.Net 3.5
and IP2.7 / .NET 4.0. In the 2.7 .exe, it appears that the imports (like "os")
are not being built into the .exe/.dll, but instead are required to be imported
in source form, e.g. "os.py" must be somewhere on sys.path. In the IP 2.5
.exe's we had been building, they would run fine on machines without the IP
standard library installed at all, in other words, with "os.py" not present on
the machine at all. We did notice that the .exe in question went from being 2.9
MB in it's IP 2.5 incarnation, down to 1.2 MB in the IP 2.7 version, and the
newer version requires that the source code for the IP standard library be on
the path. Is this a deliberate change in behavior? We never had to package the
standard library source when we sent out .exe's to customers before
Hmmm... I'm pretty sure I always had to explicitly compile and bundle the
standard library with previous versions of Python. Odd. Anyway, the simple
solution is to ensure that you add any standard library modules you use to the
set you compile and ship.
All the best,
Michael Foord
>"os" is not an assembly but a Python module from the standard library. You
>need to ensure >that the Python standard library (or the parts that you use
>and their dependencies) is on the >path.
All the best,
Michael Foord
and how do I ensure it gets found from my .exe - is there a specific env.
variable, or the Windows %PATH% e.v., or something I haven't AddReference'd
to????
Thanks,
Ken
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
--
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
