Стиллер на python с отправкой по почте

Using UPX¶

UPX is a free utility available for most operating systems.
UPX compresses executable files and libraries, making them smaller,
sometimes much smaller.
UPX is available for most operating systems and can compress
a large number of executable file formats.
See the UPX home page for downloads, and for the list of
supported executable formats.

A compressed executable program is wrapped in UPX
startup code that dynamically decompresses the program
when the program is launched.
After it has been decompressed, the program runs normally.
In the case of a PyInstaller one-file executable that has
been UPX-compressed, the full execution sequence is:

The compressed program start up in the UPX decompressor code.
After decompression, the program executes the PyInstaller bootloader,
which creates a temporary environment for Python.
The Python interpreter executes your script.

Using UPX¶

Ошибка unable to locate package в ubuntu

The compressed program start up in the UPX decompressor code.
After decompression, the program executes the PyInstaller bootloader,
which creates a temporary environment for Python.
The Python interpreter executes your script.

Testing Your New Executable#

Getting started with python and influxdb

The best way to test your new executable is on a new machine. The new machine should have the same OS as your build machine. Ideally, this machine should be as similar as possible to what your users use. That may not always be possible, so the next best thing is testing on your own machine.

The key is to run the resulting executable without your development environment activated. This means run without , , or any other environment that can access your Python installation. Remember, one of the main goals of a PyInstaller-created executable is for users to not need anything installed on their machine.

Picking up with the feed reader example, you’ll notice that running the default executable in the folder fails. Luckily the error points you to the problem:

The package requires a file. You can add this file to the build using the option. Here’s an example of how to include the required file:

This command tells PyInstaller to include the file in the folder in a new folder in your build called .

Note: The commands use the character to make the command easier to read. You can omit the when running commands on your own or copy and paste the commands as-is below provided you’re using the same paths.

You’ll want to adjust the path in the above command to match where you installed the feed reader dependencies.

Now running the new executable will result in a new error about a file.

This file is required by the feed reader project, so you’ll need to make sure to include it in your build:

Again, you’ll need to adjust the path to the file based on where you have the feed reader project.

Shortening the Command¶

Python: scrapy, selenium, beautiful soup что лучше для парсинга веб сайтов

Because of its numerous options, a full command
can become very long.
You will run the same command again and again as you develop
your script.
You can put the command in a shell script or batch file,
using line continuations to make it readable.
For example, in GNU/Linux:

pyinstaller --noconfirm --log-level=WARN \
    --onefile --nowindow \
    --add-data="README:." \
    --add-data="image1.png:img" \
    --add-binary="libfoo.so:lib" \
    --hidden-import=secret1 \
    --hidden-import=secret2 \
    --upx-dir=/usrlocalshare \
    myscript.spec

Or in Windows, use the little-known BAT file line continuation:

Building Mac OS X App Bundles¶

Under Mac OS X, PyInstaller always builds a UNIX executable in
.
If you specify , the output is a folder named
containing supporting files and an executable named .
If you specify , the output is a single UNIX executable
named .
Either executable can be started from a Terminal command line.
Standard input and output work as normal through that Terminal window.

If you specify with either option, the folder
also contains an OS X application named .

As you probably know, an application is a special type of folder.
The one built by PyInstaller contains a folder always named
which contains:

Use the argument to specify a custom icon for the application.
It will be copied into the folder.
(If you do not specify an icon file, PyInstaller supplies a
file with the PyInstaller logo.)

Use the argument to add a bundle identifier.
This becomes the used in code-signing
(see the PyInstaller code signing recipe
and for more detail, the Apple code signing overview technical note).

PyInstaller Overview

PyInstaller bundles a Python application and all its dependencies into a single
package. The user can run the packaged app without installing a Python
interpreter or any modules.

Documentation:
Website:
Code:
Donate:	Bitcoin: 1JUFjawzWDR7Tc8z9TKXstVFdjkDY9FbtK

PyInstaller reads a Python script written by you. It analyzes your code
to discover every other module and library your script needs in order to
execute. Then it collects copies of all those files – including the active
Python interpreter! – and puts them with your script in a single folder, or
optionally in a single executable file.

PyInstaller is tested against Windows, Mac OS X, and Linux. However, it is not
a cross-compiler: to make a Windows app you run PyInstaller in Windows; to make
a Linux app you run it in Linux, etc. PyInstaller has been used successfully
with AIX, Solaris, and FreeBSD, but is not tested against them.

Main Advantages

Works out-of-the-box with any Python version 2.7 / 3.4-3.7.
Fully multi-platform, and uses the OS support to load the dynamic libraries,
thus ensuring full compatibility.
Correctly bundles the major Python packages such as numpy, PyQt4, PyQt5,
PySide, Django, wxPython, matplotlib and others out-of-the-box.
Compatible with many 3rd-party packages out-of-the-box. (All the required
tricks to make external packages work are already integrated.)
Libraries like PyQt5, PyQt4, PySide, wxPython, matplotlib or Django are fully
supported, without having to handle plugins or external data files manually.
Working code signing on OS X.
Bundles MS Visual C++ DLLs on Windows.

PyInstaller is available on PyPI. You can install it through pip:

pip install pyinstaller

Windows NT services

You can build Windows NT services by passing a service keyword
argument to the setup function, the value must be a list of Python
module names containing a service class (identified by the _svc_name_
attribute):

# setup.py
from distutils.core import setup
import py2exe

setup(service=)

Optionally, you can specify a ‘cmdline-style’ attribute to py2exe, with
valid values being ‘py2exe’ (the default), ‘pywin32’ or ‘custom’. ‘py2exe’
specifies the traditional command-line always supported by py2exe. ‘pywin32’
supports the exact same command-line arguments as pywin32 supports (ie, the
same arguments supported when running the service from the .py file.)
‘custom’ means that your module is expected to provide a ‘HandleCommandLine’
function which is responsible for all command-line handling.

Using «bundle_files» and «zipfile»

An easier (and better) way to create single-file executables is to set bundle_files to 1 or 2, and to set zipfile to None. This approach does not require extracting files to a temporary location, which provides much faster program startup.

Valid values for bundle_files are:

3 (default)	don’t bundle
2	bundle everything but the Python interpreter
1	bundle everything, including the Python interpreter

If zipfile is set to None, the files will be bundle within the executable instead of library.zip. Note: you will still be required to include the MSVC runtime DLL with your application, which should be located in the dist directory along side the executable (named MSVCRXX.dll, where XX = revision number).

Here is a sample setup.py:

from distutils.core import setup
import py2exe, sys, os

sys.argv.append('py2exe')

setup(
    options = {'py2exe': {'bundle_files': 1}},
    windows = ,
    zipfile = None,
)

PyInstaller#

PyInstaller abstracts these details from the user by finding all your dependencies and bundling them together. Your users won’t even know they’re running a Python project because the Python Interpreter itself is bundled into your application. Goodbye complicated installation instructions!

PyInstaller performs this amazing feat by introspecting your Python code, detecting your dependencies, and then packaging them into a suitable format depending on your Operating System.

There are lots of interesting details about PyInstaller, but for now you’ll learn the basics of how it works and how to use it. You can always refer to the if you want more details.

What are all those files?

myprog.exe	The actual executable. You can select a custom icon by using some specific target options (see CustomIcons)
python??.dll	the python interpreter library. This is the brain of your executable
library.zip	This is a standard zip file where all the pure source modules will be inserted (using the «zipfile» option, you can also select to put that file in a sub-directory and with a different name)
*.pyd	The pyd files are actually standard Windows DLL (I used the useful depends.exe to check things around). They are also standard modules for Python. A Python program can import those pyd. Some applications build pyd to provide accelerated features. Also they are necessary to provide support to native functions of the operating system (see also CTypes to never have to use SWIG again!). Those files also follow into the subdirectory where library.zip will be installed
*.dll	some pyd probably have some DLL dependencies, and here they come
w9xpopen.exe	This is needed on Win9x platform.

To run your program needs all these files. But it might happen that these are not enough. For examples, encodings are imported «by name». If you use a feature that requires encodings, you will need to put an option to include encodings unconditionally or to import them explicitly from one of your script. (see EncodingsAgain and EvenMoreEncodings).

Some other modules (eg pyserial-pyparallel) also conditionally import modules for each platform. You can avoid the warning by putting the correct «ignores» options in py2exe. Last but not least, modules like pygtk seem to create a module reference on-the-fly and therefore the corresponding warnings also are harmless (see ExcludingDlls to learn how to correct that).

An important point to note: the main script (the one passed as an option to «windows» or «console» in your setup file) is not put with all the other files in the library.zip. Instead it is byte-compiled (see OptimizedBytecode for some details on optimization) and inserted into a named resource in the executable shell. This technique also allows you to insert binary string in the final executable (very nice if you want to add a custom version tag) through the usage of the «other_resources» options for the target (see CustomDataInExe).

The bundle option

By default py2exe creates these files in the dist directory which
you must deploy:

The --bundle <level> or -b <level> command line switch will
create less files because binary extensions, runtime dlls, and even
the Python-dll itself is bundled into the executable itself, or inside
the library-archive if you prefer that.

The bundled pyds and dlls are never unpacked to the file system,
instead they are transparently loaded at runtime from the bundle. The
resulting executable appears to be statically linked.

Specifying a level of 2 includes the .pyd and .dll files into the
zip-archive or the executable. Thus, the dist directory will contain
your exe file(s), the library.zip file (if you haven’t specified
‘zipfile=None’), and the python dll. The advantage of this scheme is
that the application can still load extension modules from the file
system if you extend sys.path at runtime.

Using a level of 1 includes the .pyd and .dll files into the
zip-archive or the executable itself, and does the same for
pythonXY.dll. The advantage is that you only need to distribute one
file per exe, which will however be quite large. Another advantage is
that inproc COM servers will run completely isolated from other Python
interpreters in the same exe. The disadvantage of this scheme is that
it is impossible to load other extensions from the file system, the
application will crash with a fatal Python error if you try this. I
have still to find a way to prevent this and raise an ImportError
instead — any suggestions how this can be implemented would be very
welcome.

The bundle-option has been tested with some popular extensions, but of
course there’s no guarantee that any extension will work in bundled
form — be sure to test the executable (which you should do anyway).

Helping PyInstaller Find Modules¶

Extending the Path

If Analysis recognizes that a module is needed, but cannot find that module,
it is often because the script is manipulating .
The easiest thing to do in this case is to use the option
to list all the other places that the script might be searching for imports:

pyi-makespec --paths=/pathtothisdir \
             --paths=/pathtootherdir myscript.py

These paths will be noted in the spec file.
They will be added to the current during analysis.

Listing Hidden Imports

If Analysis thinks it has found all the imports,
but the app fails with an import error,
the problem is a hidden import; that is, an import that is not
visible to the analysis phase.

Hidden imports can occur when the code is using ,

or perhaps or .
Hidden imports can also occur when an extension module uses the
Python/C API to do an import.
When this occurs, Analysis can detect nothing.
There will be no warnings, only an ImportError at run-time.

To find these hidden imports,
build the app with the flag
(see above)
and run it.

Once you know what modules are needed, you add the needed modules
to the bundle using the command option,
or by editing the spec file,
or with a hook file (see below).

Extending a Package’s

Python allows a script to extend the search path used for imports
through the mechanism.
Normally, the of an imported module has only one entry,
the directory in which the was found.
But is free to extend its to include other directories.
For example, the module actually resolves to
.
This is because appends to its .

Because the of an imported module
is not actually executed during analysis,
changes it makes to are not seen by PyInstaller.
We fix the problem with the same hook mechanism we use for hidden imports,
with some additional logic; see below.

Note that manipulations of hooked in this way apply only
to the Analysis.
At runtime all imports are intercepted and satisfied from within the
bundle. is resolved the same
way as , and
knows nothing of .

Once in a while, that’s not enough.

Project details

Homepage

Classifiers

Development Status

6 — Mature
Environment

Console
Intended Audience
- Developers
- Other Audience
- System Administrators
License

OSI Approved :: GNU General Public License v2 (GPLv2)
Natural Language

English
Operating System
- MacOS :: MacOS X
- Microsoft :: Windows
- POSIX
- POSIX :: AIX
- POSIX :: BSD
- POSIX :: Linux
- POSIX :: SunOS/Solaris
Programming Language
- C
- Python
- Python :: 2
- Python :: 2.7
- Python :: 3
- Python :: 3.4
- Python :: 3.5
- Python :: 3.6
- Python :: 3.7
- Python :: Implementation :: CPython
Topic
- Software Development
- Software Development :: Build Tools
- Software Development :: Interpreters
- Software Development :: Libraries :: Python Modules
- System :: Installation/Setup
- System :: Software Distribution
- Utilities

Capturing Windows Version Data¶

A Windows app may require a Version resource file.
A Version resource contains a group of data structures,
some containing binary integers and some containing strings,
that describe the properties of the executable.
For details see the Microsoft Version Information Structures page.

Version resources are complex and
some elements are optional, others required.
When you view the version tab of a Properties dialog,
there’s no simple relationship between
the data displayed and the structure of the resource.
For this reason PyInstaller includes the command.
It is invoked with the full path name of any Windows executable
that has a Version resource:

The command writes text that represents
a Version resource in readable form to standard output.
You can copy it from the console window or redirect it to a file.
Then you can edit the version information to adapt it to your program.
Using you can find an executable that displays the kind of
information you want, copy its resource data, and modify it to suit your package.

The version text file is encoded UTF-8 and may contain non-ASCII characters.
(Unicode characters are allowed in Version resource string fields.)
Be sure to edit and save the text file in UTF-8 unless you are
certain it contains only ASCII string values.

Your edited version text file can be given with the
option to or .
The text data is converted to a Version resource and
installed in the bundled app.

In a Version resource there are two 64-bit binary values,
and .
In the version text file these are given as four-element tuples,
for example:

filevers=(2, , 4, ),
prodvers=(2, , 4, ),

The elements of each tuple represent 16-bit values
from most-significant to least-significant.
For example the value resolves to
in hex.

You can also install a Version resource from a text file after
the bundled app has been created, using the command:

The utility reads a version text file as written
by , converts it to a Version resource,
and installs that resource in the executable_file specified.

Running PyInstaller with Python optimizations¶

Note

When using this feature, you should be aware of how the Python bytecode
optimization mechanism works. When using , is set
to and statements are removed from the bytecode.
The flag additionally removes docstrings.

Using this feature affects not only your main script, but all modules
included by PyInstaller. If your code (or any module imported by your
script) relies on these features, your program may break or have
unexpected behavior.

PyInstaller can be run with Python optimization flags ( or )
by executing it as a Python module, rather than using the
command:

# run with basic optimizations
python -O -m PyInstaller myscript.py

# also discard docstrings
python -OO -m PyInstaller myscript.py

Or, by explicitly setting the environment variable
to a non-zero value:

# Unix
PYTHONOPTIMIZE=1 pyinstaller myscript.py

# Windows
set PYTHONOPTIMIZE=1 && pyinstaller myscript.py

You can use any PyInstaller options that are otherwise available with
the command. For example:

python -O -m PyInstaller --onefile myscript.py

Alternatively, you can also use the path to pyinstaller:

Discussion

I’m wondering: Is there something like Py2Exe, but for Linux?

We have some Python code that we’d like clients to be able to run, but we don’t want them to have to install Python.

I know that Python is a required install on Red Hat 9 and up, but I don’t think it is a required install on Suse, or Mandrake, or yadda yadda yadda. So, I think this would be useful. If we had somethig like Py2Exe for Linux, then we can justify using Python here at work.

The question is: Does something like this exist right now?

No, we can’t require our users to install something new. Everything has to just run, right out of the box, with zero installation.

Try googling for «freeze». It’s in the Python distribution (in fact, there’s a FAQ section called , waddayamean, is there a Py2Exe for Linux ;)).

— JohannesGijsbers

Heh! Well, I just never saw anything about Freeze online. I googled for «compile Python to executable» and stuff like that, for about 30 minutes, and never saw a single mention of Freeze. «If it’s not on the net, it may well not exist,» right?

So, Freeze will now have a place on the net: right here.

Score 1 for wiki.

— LionKimbro 2004-08-30 03:43:57

Why dont you make one yourself, it’s probably not that hard… — anon

«probably»? Anon sounds like an optimist. — RetrogradeOrbit

One other idea, still playing around with it, is pyinstaller. http://www.pyinstaller.org/. If you want a GUI for it, try PythonCard StandAloneBuilder, http://www.linux2000.org/pm.html. Seems like there might be some bugs, but some things seem to work seamlessly. —Alestan

— hipersayan_x 2009-12-22 12:34:00

is it possible to get py2exe to run on linux? I only have a linux pc and my client does not want python installed on all of there computers.

— CyberKing 2010-04-07 11:03:00

About:

Try using Teleport Me Now! to create portable programs from Linux to Windows with wine.

Is Alpha but it work fine. Here you have an real example of use:

http://sushi-huh.sourceforge.net — anonymous

It IS possible to create working executables with py2exe under Linux. I do create setups of fairly complex programs which use PyGTK and which depend on modules which are also compiled on Linux with MinGW ( ie. I do create windows setups on a 100% pure Linux system ). The one real hack I needed to do this is to call PETools for each created binary to fix the image size header field ( in PETools: «Optional Header»->»Size Of Image». Press «?» there and it will correct the size ), otherwise the application won’t run. I use InnoSetup under wine to create an actual setup. — Arne Caspari

Capturing Windows Version Data¶

Your edited version text file can be given with the
option to or .
The text data is converted to a Version resource and
installed in the bundled app.

In a Version resource there are two 64-bit binary values,
and .
In the version text file these are given as four-element tuples,
for example:

filevers=(2, , 4, ),
prodvers=(2, , 4, ),

The elements of each tuple represent 16-bit values
from most-significant to least-significant.
For example the value resolves to
in hex.

You can also install a Version resource from a text file after
the bundled app has been created, using the command:

The utility reads a version text file as written
by , converts it to a Version resource,
and installs that resource in the executable_file specified.

Run your setup script

The next step is to run your setup script. Make sure to give the py2exe command and expect to see lots and lots of output:

C:\Tutorial>python setup.py py2exe
running py2exe
*** searching for required modules ***
*** parsing results ***
creating python loader for extension 'zlib'
creating python loader for extension 'unicodedata'
creating python loader for extension 'bz2'
*** finding dlls needed ***
*** create binaries ***
*** byte compile python files ***
byte-compiling C:\Tutorial\build\bdist.win32\winexe\temp\bz2.py to bz2.pyc
byte-compiling C:\Tutorial\build\bdist.win32\winexe\temp\unicodedata.py to unicodedata.pyc
byte-compiling C:\Tutorial\build\bdist.win32\winexe\temp\zlib.py to zlib.pyc
skipping byte-compilation of c:\Python24\lib\StringIO.py to StringIO.pyc



skipping byte-compilation of c:\Python24\lib\warnings.py to warnings.pyc
*** copy extensions ***
*** copy dlls ***
copying c:\Python24\lib\site-packages\py2exe\run.exe -> C:\Tutorial\dist\hello.exe

*** binary dependencies ***
Your executable(s) also depend on these dlls which are not included,
you may or may not need to distribute them.

Make sure you have the license if you distribute any of them, and
make sure you don't distribute files belonging to the operating system.

   ADVAPI32.dll - C:\WINDOWS\system32\ADVAPI32.dll
   USER32.dll - C:\WINDOWS\system32\USER32.dll
   SHELL32.dll - C:\WINDOWS\system32\SHELL32.dll
   KERNEL32.dll - C:\WINDOWS\system32\KERNEL32.dll

C:\Tutorial>

Two directories will be created when you run your setup script, build and dist. The build directory is used as working space while your application is being packaged. It is safe to delete the build directory after your setup script has finished running. The files in the dist directory are the ones needed to run your application.