[IronPython] Python Command Line Compiler issues and questions

[Dino Viehland]

I am surprised one is behaving different.  It works for me w/ pyc if I keep the package directory on the path, but if I don't then it breaks.

I'm curious did you include all of your individual package files, or just __init__.py?  And were the packages on your path?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, January 01, 2007 8:20 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Python Command Line Compiler issues and questions

Mark Rees wrote:
> I have a simple IronPython script that will compile an IronPython
> executable
> with multiple source files
>
> http://hex-dump.googlecode.com/svn/trunk/ironpython-gdata-tutorial/tut03/makeexe.py

>
> and to handle the "if __name__ == '__main__':" idom you just need to change
> it to:
>
> if __name__ == '__main__' or __name__ == sys.executable:
>
> It's discussed in this post:
> http://hex-dump.blogspot.com/2006/08/deploying-gdata-reader-as-executable.html
>

Ahh... cool.

I've had a play with makeexe.py, it's very nice.

You can compile multiple Python files (including imports) into a single
executable.

The difficulty we had was with maintaining our package structure. We
want import semantics like 'from Main.Something import Something', which
  didn't seem to work with PYC.

It *does* seem to work (initial experiments) with makeexe.py, which is
cool. (I included the empty 'package/__init__.py' file in the arguments
to makeexe.py.)

We were intending to ship source code with our application (which has
various advantages for us - our target market includes programmers in
business environments), but we have an issue with startup time - mainly
caused by the parsing of the Python files. Precompilation could solve that.

Hmmm....

Michael Foord
http://www.voidspace.org.uk/python/index.shtml

>
> Mark
>
>
>
> On 1/1/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>>
>> Patrick O'Brien wrote:
>> > If you compile a python module using PYC and run the resulting
>> executable,
>> > the module name is no longer '__main__' and so you cannot make use of
>> the
>> > popular idiom:
>> >
>> > if __name__ == '__main__':
>> >
>> > If you don't use that idiom it makes it impossible to unit test any
>> > functions in your main module because running the unit tests imports
>> the
>> > module and runs the main code.  The alternative is to have the main
>> module
>> > be as small as possible and put the bulk of the functionality into
>> other
>> > modules that get imported by the main module.  Which would be fine if
>> there
>> > was a way to include those modules in the resulting exe created by PYC,
>> but
>> > that doesn't seem to happen for me.  Which means the .py files would
>> > have to
>> > ship as well as the .exe and the two .dll files (IronMath.dll and
>> > IronPython.dll).  And substituting a .pyo file does not work, so what
>> would
>> > ship in my app is the source code and for this particular app that
>> would
>> > not
>> > be a good thing.
>> >
>> > The PYC program lets you specify multiple .py files, but I don't
>> understand
>> > what that means.  One file can be marked as main, which is what gets
>> > executed.  What I don't understand is how the other .py files get used.
>> > The
>> > one example of this in the documentation was not terribly helpful for
>> me.
>> >
>> > Anyone have any suggestions?  Did I miss something in my understanding
>> of
>> > PYC?  How are others packaging their IronPython apps for
>> distribution to
>> > customers?
>> >
>>
>> We asked about IronPython supporting compiling Python modules so that
>> they can be imported from, and were told that it probably wouldn't make
>> it into IronPython 1.X.
>>
>> That means (my understanding) that PYC can only be used for compiling a
>> single script with no dependencies (unless you're happy about shipping
>> those dependencies as source files).
>>
>> Luckily for us at Resolver, I think we're happy to ship source files. If
>> you're not happy with this you'll need to resort to other means for
>> obfuscation (like encryption of source where the decryption is in the
>> compiled part). This will confound casual observers, but IL is easily
>> (relatively) decompiled and so will not stop the determined attacker
>> from breaking your encryption.
>>
>> Michael
>> http://www.voidspace.org.uk/python/articles.shtml
>>
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at lists.ironpython.com
>> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>> > No virus found in this incoming message.
>> > Checked by AVG Free Edition.
>> > Version: 7.1.409 / Virus Database: 268.16.0/610 - Release Date:
>> 30/12/2006
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.16.1/611 - Release Date: 31/12/2006

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com