I'm coding a Python application. If I convert it into a .exe (.pyw/.py to .exe), will it be runnable on other PC's without python?
Your best option is probably cx_Freeze, which will bundle all the needed files into one convenient package (and it's fairly well maintained).
Related
Is there any way to create executable binaries from Ruby/Rake task?
I have simple FileUtil tool written in ruby and I'd like to package it somehow into script that can be run or OSX, Linux or Windows. Is there any way to do that?
Ruby is an interpreted language and not a compiled one like C or Java. Then answering your question is not so easy.
But there are some tools that permit you to protect your source code (encrypting) and creating some packages that are runnable cross platform (but in this case you should ever resolve any dependency).
This question covers pretty good how you can distribuite your code without (or encrypting) your source code: Can you Distribute a Ruby on Rails Application without Source?
Other useful tools that I have founded in these moments:
- Compiling a rake https://github.com/luislavena/rake-compiler
- Debian (.deb) packaging http://crohr.me/pkgr/
can someone give a link to lrelease binary for windows?
I can't seem to find it everywhere.
I have a server app that translates the ui dynamically via web translate engine (like google translate) and translates the entries in the .ts file. Now I need to generate a .qm from .ts and return it to the client.
So I need to put the lrelease utility on the server. Don't want to install the whole qt framework. Just the .exe and maybe some depending .dll-s.
// UPDATE
Thanks for replies. I managed to get it working in Windows.
Same question, but looking for Linux (Ubuntu) binary.
How can I check just lrelease dependencies.
I know it is in the qt4-dev-tools package, but it depends on almost whole Qt.
So is there any way to check only the lrelease dependencies?
You could download e.g. [QT for VS 2008][1], install it on some machine and copy lrelease and the required DLLs (I'd assume QtCore and QtXml) from there to the server. I don't think you'll find up-to-date standalone binaries on the net.
I downloaded everything described as in pygtk for installation. Everything went fine until when I tried to type "import gtk", it threw an ImportError as follows:
from gtk import _gtk
ImportError: DLL load failed: ...(something unreadable)
Then I re-install the pygtk-2.22.0 again, the same problem existed. So what to do please? Thanks in advance!
The error you describe is usually caused by the python bindings (pygtk/pygobject/pycairo) being unable to load a dll it needs to function properly. Most of those errors are either caused by:
the GTK+ runtime not being on your PATH environment variable. This has long been
the advice on how to get pygtk working on Windows. Please don't change your user
or system PATH environment variable, it is no longer needed with the all-in-one
installer.
multiple GTK+ runtime versions are on your PATH environment variable and the first
(leftmost) one is not compatible with the pygtk/pygobject/pycairo versions you use.
This is why adding the GTK+ runtime to your PATH environment variable is a bad idea:
it is easy to mix up versions (sometimes GTK+ related installers add their bin
directory to PATH on installation which contains an older or incomplete runtime).
a rare case where some software package installed libintl.dll and iconv.dll into
%WINDIR%\system or %WINDIR%\sytem32
The most straightforward way to avoid the dll hell described above is to use the
PyGTK All-in-one installer (http://download.gnome.org/binaries/win32/pygtk/2.22/).
It contains both the Python bindings, the GTK+ runtime and even Glade and does
no longer require you to change the PATH environment variable.
Small warning: if you decide to use the all-in-one installer, you'll have to uninstall
the separate pygtk/pygobject/pycairo packages you've used before (or you'll be in
a world of trouble...)
read the source code, perhaps there is a need for a specific version of pygtk
edit the source code to work with your pygtk version
I had this issue as well. You didn't mention for sure in your answer, so I'll suggest the obvious (well...the obvious to people that have used it a while, perhaps). Did you use the following three lines of code to import? You have to use these, in order, to import PyGTK.
I'm assuming your version here is 2.24 like mine. If not, change it to the version you have.
import pygtk
pygtk.require('2.24')
import gtk
That should suffice in importing gtk.
Problem
As others have noted, don't put gtk in the path. I know, its tempting, and it works for XYZ, but it (to say the least) gets confusing. Dependency hell is bad enough on a platform like Linux which tries to make it easy for you.
For clarification, what the PyGTK All In One does for you is to install (what appears to be) a full gtk+ runtime directly in your python packages folder, so e.g. in C:\Python\Lib\site-packages\gtk-2.0\runtime
Solution
NOTE: %YOURPYTHONPATH% is an EXAMPLE variable which contains the path of your Python installation (e.g. C:\Python, or C:\Python27, or whatever it actually is). I suggest setting %PYTHON_DIR% or %PYTHON_PATH% if you want to use a variable to do this, as more programs are likely to use this.
To get your XYZ program requiring GTK to work, add %YOURPYTHONPATH%\Lib\site-packages\gtk-2.0\runtime\bin to the PATH when running your program; the correct versions of the DLLs it needs to link against are in that folder. All other GTK+ runtimes I had installed (GTK+/GTK2-Runetime) gave me errors.
Again; Do not attempt to set a user or system level variable (don't open up the dialog pictured below) as this will likely cause problems for you later unless you VERY sure you know what you are doing. If you are reading this, you most likely don't know as much as you think you do. Instead, alter the path in a cmd prompt, or use a batch/script file to set it up for you.
After you install the pygtk.org package, install each of these in the following order:
pycairo-1.8.6.win32-py2.6.exe
pygobject-2.20.0.win32-py2.6.exe
pygtk-2.16.0+glade.win32-py2.6.exe
gtk+-bundle_2.16.6-20100912_win32.zip
For more information:
http://freetstar.com/windows7-pygtk-gtk/
I got the secusses according the link on my PC.
I need to set up sqllite for Perl on a Windows box. However - Perl is probably being run over the network from a central server, and I do not know what modules will be available on initial running of my script.
I can guarantee Perl 5.8+ (activestate) or Perl 5.10+ (strawberry).
Therefore, I need to package sqlite & the associated Perl module(s) in the project directory itself. Having Goggled around, I don't see any immediate zipfile to do this.
DBD::SQLite is included into Strawberry (any version) and ActivePerl (AFAIK starting from 5.8.8 build 820). For other modules you can use PAR::Packer to package into .exe.
The DBD::SQlite distribution should have everything you need for SQLite. It comes with the Perl interface and all the SQLite stuff you need. You'll also need the basic DBI package too.
However, I encourage you to set up whatever application you have to install as a Perl distribution with dependencies, etc. Then you just install your application as a Perl module with the normal Perl tools. You specify whatever you need in the tool configuration at installation time. That way you aren't creating some new system that you have to explain to other Perl programmers, create new tools for, or maintain in some odd way.
You can even set up your own internal mini-CPAN with just the modules you need so you can control it within your network. See, for instance, my DPAN stuff.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I already attempted using py2exe (not compatible with ipy) and PYC (out of date). Can anyone point me in the direction of a good compiler?
You can use pyc.py, the Python Command-Line Compiler, which is included in IronPython since version 2.6 to compile a Python script to an executable. You find it at %IRONPYTONINSTALLDIR%\Tools\Scripts\pyc.py on your hard disk.
Example
Let's assume you have a simple script test.py that just prints out something to console. You can turn this into an executable with the following command-line (assuming that the IronPython directory is the current directory and that test.py is in there, too):
ipy.exe Tools\Scripts\pyc.py /main:test.py /target:exe
Note: If you are using forms and don't want a console window to open, you want to use /target:winexe instead of /target:exe.
The result will be two files, test.dll and test.exe. test.dll will contain your actual script code, while test.exe is just a launcher for test.dll. You can distribute this EXE and DLL to other computers which do not have IronPython installed if you include the files
IronPython.dll,
Microsoft.Dynamic.dll,
Microsoft.Scripting.Core.dll,
Microsoft.Scripting.Debugging.dll,
Microsoft.Scripting.dll,
Microsoft.Scripting.ExtensionAttribute.dll and
IronPython.Modules.dll (sometimes needed).
Also see the blog entry IronPython - how to compile exe.
This is a long standing question about which there is very little information on the internet. The only known solution I can find is at http://community.sharpdevelop.net/blogs/mattward/archive/2010/03/16/CompilingPythonPackagesWithIronPython.aspx which uses SharpDevelop. However, this solution is impractical because any semi-complex python project will do a LOT of module imports, and the SharpDevelop solution requires you to create a project per import. I started at it and gave up after about thirty new projects, better to write an automated solution!
So here's my solution, and I'll warn you right now it's not being released as a proper project for good reason:
#!/usr/bin/env python
# CompileToStandalone, a Python to .NET ILR compiler which produces standalone binaries
# (C) 2012 Niall Douglas http://www.nedproductions.biz/
# Created: March 2012
import modulefinder, sys, os, subprocess, _winreg
if len(sys.argv)<2:
print("Usage: CompileEverythingToILR.py <source py> [-outdir=<dest dir>]")
sys.exit(0)
if sys.platform=="cli":
print("ERROR: IronPython's ModuleFinder currently doesn't work, so run me under CPython please")
sys.exit(1)
sourcepath=sys.argv[1]
destpath=sys.argv[2][8:] if len(sys.argv)==3 else os.path.dirname(sys.argv[0])
ironpythonpath=None
try:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, None)
except Exception as e:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\Wow6432Node\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, "")
except Exception as e:
pass
finally:
if ironpythonpath is not None:
_winreg.CloseKey(keyh)
print("IronPython found at "+ironpythonpath)
else:
raise Exception("Cannot find IronPython in the registry")
# What we do now is to load the python source but against the customised IronPython runtime
# library which has been hacked to work with IronPython. This spits out the right set of
# modules mostly, but we include the main python's site-packages in order to resolve any
# third party packages
print("Scanning '"+sourcepath+"' for dependencies and outputting into '"+destpath+"' ...")
searchpaths=[".", ironpythonpath+os.sep+"Lib"]
searchpaths+=[x for x in sys.path if 'site-packages' in x]
finder=modulefinder.ModuleFinder(searchpaths)
finder.run_script(sourcepath)
print(finder.report())
modules=[]
badmodules=finder.badmodules.keys()
for name, mod in finder.modules.iteritems():
path=mod.__file__
# Ignore internal modules
if path is None: continue
# Ignore DLL internal modules
#if '\\DLLs\\' in path: continue
# Watch out for C modules
if os.path.splitext(path)[1]=='.pyd':
print("WARNING: I don't support handling C modules at '"+path+"'")
badmodules.append(name)
continue
modules.append((name, os.path.abspath(path)))
modules.sort()
print("Modules not imported due to not found, error or being a C module:")
print("\n".join(badmodules))
raw_input("\nPress Return if you are happy with these missing modules ...")
with open(destpath+os.sep+"files.txt", "w") as oh:
oh.writelines([x[1]+'\n' for x in modules])
cmd='ipy64 '+destpath+os.sep+'pyc.py /main:"'+os.path.abspath(sourcepath)+'" /out:'+os.path.splitext(os.path.basename(sourcepath))[0]+' /target:exe /standalone /platform:x86 /files:'+destpath+os.sep+'files.txt'
print(cmd)
cwd=os.getcwd()
try:
os.chdir(destpath)
retcode=subprocess.call(cmd, shell=True)
finally:
os.chdir(cwd)
sys.exit(retcode)
This was written against IronPython v2.7.2 RC1 using its new standalone binary feature, and indeed it does work. You get a standalone .exe file which is totally self-contained - it needs nothing else installed. The script works by parsing the imports for the supplied script and sending the entire lot to pyc.py. That's the good news.
The bad news is as follows:
IronPython v2.7.2 RC1's ModuleFinder doesn't appear to work, so the above script needs to be run using CPython. It then uses CPython's ModuleFinder but against IronPython's customised runtime library. Yeah, I'm amazed it works as well ...
The binaries output start at about 8Mb. A simple unit test weighed in at 16Mb. There's a lot of stuff that doesn't need to be in there e.g. it throws it Wpf support and a bit more, but still they aren't small.
Load times are much slower than non-standalone. Think about forty seconds for a standalone unit test on a fast Intel Core 2 versus about three seconds for non-standalone. If compiled just for x86, that drops to ten seconds.
Run time performance is slower than non-standalone by about 40%. If compiled just for x86, performance approximately doubles. This is why I left in the /platform:x86 above.
There is a well known bug in CPython's encodings and codecs support where ModuleFinder doesn't include any codec support at all unless you manually specify it. So, for example, if you are using UTF-8 with codecs.open() then you NEED a "from encodings import utf_8 as some_unique_identifier" to force the dependency.
The above assumes a modified pyc.py which can take a /files parameter as the command line length limit easily gets exceeded. You can modify your own pyc.py trivially, if not I've submitted the enhancement for inclusion into the next IronPython.
So there you go. It works, but the solution still needs a lot more maturing. Best of luck!
Check out the IronPython Samples Page
About half way down the page:
Pyc - Python Command-Line Compiler
This sample shows developers how to create .NET executables directly out of IronPython scripts. The readme.htm in the download will get you started.
IronPython’s Hosting APIs can be used to compile Python scripts into DLLs, console executables, or Windows executables. The pyc.py script included in this tutorial leverages these hosting APIs and can be used to compile other Python scripts. It provides a variety of flags such as the ability to specify the target platform of the .NET assembly (e.g., x64).
While the assemblies produced by the IronPython Hosting APIs are true .NET assemblies, the dynamic nature of the Python language makes it difficult to use these from other .NET languages. In short, this means that attempting to import Python types into other .NET languages such as C# is not recommended.
Edit: Just noticed that you mentioned PYC was out of date. What makes it so? The IronPython crew seem to still be promoting it, so I would imagine that it's not that far gone.
I had a bit of trouble trying to implement this solution.
This is what I did:
Download pyc from here.
This took me more searching than it should have because it seems that pyc is hard to find (and I think, a little out of date)
I extracted the pyc folder from the zip file and added it to my IronPython folder in C:\Program Files
Now I tried running this command on the windows console, as instructed by the readme in the pyc download:
ipy.exe pyc.py other_hw.py /main:console_hw.py
It gave me this error:
Traceback (most recent call last):
File "pyc\pyc.py", line 35, in pyc\pyc.py
AttributeError: attribute 'CompilerSink' of 'namespace#' object is read-only
I made the following change to line 35:
Before: class PycSink(Hosting.CompilerSink):
After: class PycSink():
Saving the file proved to be a problem due to permissions, so I copied the contents of pyc.py into a new IDLE window (to create a copy), deleted the existing copy of pyc.py and saved the copy as pyc.py in the same location. This takes care of permissions issues and allows changes.
After making this change, I tried running the this command again:
ipy.exe pyc.py other_hw.py /main:console_hw.py
However, this time, I got the following error:
Traceback (most recent call last):
File "pyc\pyc.py", line 170, in pyc\pyc.py
File "pyc\pyc.py", line 56, in Main
AttributeError: attribute 'ResourceFile' of 'namespace#' object is read-only
At this point, I took stock of the fact that it is now 1 AM and I have a midterm tomorrow, so I undid the changes and shut it down.
Please let me know if you have a solution, or any advancements on mine.
Yes I have found it too difficult to compile an exe so I have switched back to using standard Python. They should give a good tutorial on it on the IronPython site