I am new in python and pyqt5. I wrote a simple project by python and pyqt5 and now i want to close source code to not seen my source code. I think by obfuscate i can do this so i have installed pyminifier.
sudo apt install python-setuptools
pip3 install pyminifier
In my project i have a few class. By this command i can obfuscate one class of my project:
pyminifier --obfuscate --gzip MainWindow.py
import zlib, base64
exec(zlib.decompress(base64.b64decode('eJytVU1v2zAMvftXaLnUGQJtl10G+NAmHbAObfPRIAWGwVBtylZrS64k56PYj59oO46dpNtlh8QW+UQ9PlI01yonS3HLhF.....
The above output is shown in my terminal after running pyminifier --obfuscate.
Does it commend must be run for each class and copy output code to other new file?
If i do, I think these class's that imported together properly do not known each other and finally application do not be run!!! I am right?
Edit
I obfuscate entrypoint of my project by this command:
pyminifier --obfuscate --gzip Main.py
import zlib, base64
exec(zlib.decompress(base64.b64decode('eJzLzC3ILypRKK4s5sqyBZJ6qRWZJVzuYGZiUXoZV1pRfq5CQGVgialeYEl4Zkp6akmxQiZEV6BjQUFOZnJiSWZ+HkShb2JmXnhmXkp+OUwNQgSomMvHFlmPhrsmV6UtigoNTa4sDR+gK1KTNTQ1uQAalDgb')))
# Created by pyminifier (https://github.com/liftoff/pyminifier)
and i copied this codes into other file.py and i run app but i got Error:
python new.py
Traceback (most recent call last):
File "new.py", line 2, in <module>
exec(zlib.decompress(base64.b64decode('eJzLzC3ILypRKK4s5sqyBZJ6qRWZJVzuYGZiUXoZV1pRfq5CQGVgialeYEl4Zkp6akmxQiZEV6BjQUFOZnJiSWZ+HkShb2JmXnhmXkp+OUwNQgSomMvHFlmPhrsmV6UtigoNTa4sDR+gK1KTNTQ1uQAalDgb')))
File "<string>", line 8
j(L.exec())
^
SyntaxError: invalid syntax
Are you running a Python 3 program with Python 2? The error message only makes sense if you are using Python 2, where exec was a keyword.
For obfuscating multiple files, see http://liftoff.github.io/pyminifier/pyminifier.html:
Pyminifier can now minify/obfuscate an arbitrary number of Python scripts in one go. For example, ./pyminifier.py -O *.py will minify and obfuscate all files in the current directory ending in .py. To prevent issues with using differentiated obfuscated identifiers across multiple files, pyminifier will keep track of what replaces what via a lookup table to ensure foo_module.whatever is gets the same replacement across all source files. Added in version 2.0
Related
I have two repos both pip install a package that I upload.
In the package I have set an argparser for taking command line arguments.
However, my current method of using the command line options of the src script is to add two identical scripts in both repos that import the module and call the function that I need (same one as defined for command line).
Is there a way I could call something like
script:
python3 {get-src-path} --options 1
in the .gitlab-ci.yml scripts?
Or even embedding Python code like this?
script:
python3
{entered interactive mode}
import <package-name>
package.function()
exit()
{return to bash}
I created a project that follows the example in MutPy's README file.
However, when I run mut.py --target calculator --unit-test test_calculator -m, it just opens mut.py instead of actually running MutPy.
The file has the following content:
#!c:\users\admin\appdata\local\programs\python\python39\python.exe
import sys
from mutpy import commandline
if __name__ == '__main__':
commandline.main(sys.argv)
The README doesn't mention any other configurations that need to be done and says that it should be compatible with Python 3.3+ (I'm on Python 3.9.6).
Is there something I'm doing wrong?
Are you runing this from cmd.exe?
If so try:
python.exe mut.py --target calculator --unit-test test_calculator -m
Note that you need python in your PATH Variable.
It will probably also work if you set python as the default application for .py files.
I am in the process of porting a Ruby file used in our build system to Python. The file looks for Depends lines in a debian/control file in our repository, checks every dependency, and apt-get installs everything that isn't installed. I am trying to reproduce this functionality.
As part of porting this to Python, I looked at the deb_pkg_tools module. I pip installed it and created a simple script, install-dep2.py.
#!/usr/bin/python
import deb_pkg_tools
controlDict = deb_pkg_tools.control.load_control_file('debian/control')
However, when I run this script, I get the following error:
$ build/bin/install-dep2.py
Traceback (most recent call last):
File "build/bin/install-dep2.py", line 4, in <module>
controlDict = deb_pkg_tools.control.load_control_file('debian/control')
AttributeError: 'module' object has no attribute 'control'
The debian/control file exists:
$ ls -l debian/control
-rw-rw-r-- 1 stephen stephen 2532 Jul 13 14:28 debian/control
How can I process this debian/control file? I don't need to use deb_pkg_tools if there is a better way.
The problem you have is not that Python thinks that debian/control does not exist, but rather that it seems like deb_pkg_tools.control does not exist.
I would use the python-debian package from Debian to parse the control file if I were you. Here is the code that will parse the control file to get the dependencies. It should work even for packages with multiple binary packages.
import deb822
for paragraph in deb822.Deb822.iter_paragraphs(open('debian/control')):
for item in paragraph.items():
if item[0] == 'Depends':
print item[1]
Each item in the above example is a tuple that pairs the "key" with the "value", so item[0] gives us the "key" and item[1] gives us the "value".
Obviously the above sample just prints out the dependencies as they are in the control file, so the dependencies aren't in a format that is suitable to directly plug into apt-get install. Also, by parsing the control file, I got stuff like ${python:Depends} in addition to actual package names, so that is something you will have to consider. Here is an example of the output I got from the above example:
joseph#crunchbang:~$ python test.py
bittornado,
${python:Depends},
python-psutil,
python-qt4,
python-qt4reactor,
python-twisted,
xdg-utils,
${misc:Depends},
${shlibs:Depends}
I found this bug report and the python-debian source code to be quite useful resources when answering your question.
You might want to have a look into mk-build-deps (from the devscripts package) that is a standard script that already does what you want to achieve.
$ mk-build-deps -i -s sudo
This question already has answers here:
Is there a standard way to create Debian packages for distributing Python programs?
(5 answers)
Closed 5 years ago.
Aim
To create an installable .deb file (or package). Which when clicked would install the software on a Linux machine and an icon would be put on the GNOME panel. So as to launch this application from there.
What I have referred to
I referred to two debianizing guides.
Guide 1
Guide 2
The first one had a video which was impossible to understand, partly because of the accent and partly because it was hopelessly outdated.(it was uploaded in 2007)
And the second one was completely text. I got till the 4th Step, Builds the package. But when I did it I got output that did not match what was given in the guide.
What I require
I have a simple python program. It takes your age and then prints back out if the age is below, equal to, or above 18 years. There is just one file and no other dependency for this program. And I want to build this into a .deb.
Specs
-Python 2.7
-Linux Mint
Edit
I followed the exact directory structure as you instructed as you. And replaced all myscript with cowsandbulls. The build completed and I got the Debian. When I installed it and then ran the command cowsandbulls from the terminal I got the following error:
Traceback (most recent call last):
File "/usr/bin/cowsandbulls", line 9, in <module>
load_entry_point('cowsandbulls==1.0', 'gui_scripts', 'cowsandbulls')()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 337, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2311, in load_entry_point
return ep.load()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2017, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named cowsandbulls
I just tested stdeb (see https://pypi.python.org/pypi/stdeb), a Python package for turning any other Python package into a Debian package.
First I installed stdeb:
apt-get install python-stdeb
Then I made a simple script called myscript.py with the following contents:
def main():
print "Hello world, says myscript!"
# wait for input from the user
raw_input()
if __name__ == '__main__':
main()
Importantly, your directory structure should be:
somewhere/myscript/
setup.py
myscript/
__init__.py
myscript.py
In the setup.py file, you do something like:
import os
from setuptools import setup
from nvpy import nvpy
setup(
name = "myscript",
version = "1.0",
author = "Charl P. Botha",
author_email = "cpbotha#vxlabs.com",
description = "Demo of packaging a Python script as DEB",
license = "BSD",
url = "https://github.com/cpbotha/nvpy",
packages=['myscript'],
entry_points = {
'console_scripts' : ['myscript = myscript.myscript:main']
},
data_files = [
('share/applications/', ['vxlabs-myscript.desktop'])
],
classifiers=[
"License :: OSI Approved :: BSD License",
],
)
The console_scripts directive is important, and it'll create an executable script called my_script, which will be available system-wide after you install the resultant DEB. If your script uses something like tkinter or wxpython and has a graphical user interface, you should use gui_scripts instead of console_scripts.
The data_files directive will install a suitable desktop file into /usr/share/applications, so that you can also start myscript from your desktop environment. vxlabs-myscript.desktop looks like this:
[Desktop Entry]
Version=1.0
Type=Application
Name=myscript
Comment=Minimal stdeb example
# myscript should wait for user input at the end, else the terminal
# window will disappear immediately.
Exec=myscript
Icon=/usr/share/icons/gnome/48x48/apps/file-manager.png
Categories=Utility;
# desktop should run this in a terminal application
Terminal=true
StartupNotify=true
StartupWMClass=myscript
To build the DEB, you do the following in the top-level myscript:
python setup.py --command-packages=stdeb.command bdist_deb
Which will create a .deb in the deb_dist directory.
After having installed the DEB I created like this, I could run myscript from the command-line, and I could also invoke it from my desktop environment.
Here's a GitHub repository with the example code above: https://github.com/cpbotha/stdeb-minimal-example
The right way of building a deb package is using dpkg-buildpackage, but sometimes it is a little bit complicated. Instead you can use dpkg -b <folder> and it will create your Debian package.
These are the basics for creating a Debian package with dpkg -b <folder> with any binary or with any kind of script that runs automatically without needing manual compilation (Python, Bash, Pearl, and Ruby):
Create the files and folders in order to recreate the following structure:
ProgramName-Version/
ProgramName-Version/DEBIAN
ProgramName-Version/DEBIAN/control
ProgramName-Version/usr/
ProgramName-Version/usr/bin/
ProgramName-Version/usr/bin/your_script
The scripts placed at /usr/bin/ are directly called from the terminal. Note that I didn't add an extension to the script.
Also, you can notice that the structure of the deb package will be the structure of the program once it's installed. So if you follow this logic if your program has a single file, you can directly place it under ProgramName-Version/usr/bin/your_script, but if you have multiple files, you should place them under ProgramName-Version/usr/share/ProgramName/all your files and place only one file under /usr/bin/ that will call your scripts from /usr/share/ProgramName/.
Change all the folder permission to root:
chown root:root -R /path/to/ProgramName-Version
Change the script's permissions:
chmod 0755 /path/to/the/script
Finally, you can run: dpkg -b /path/to/the/ProgramName-Version and your deb package will be created! (You can also add the post/pre inst scripts and everything you want; it works like a normal Debian package.)
Here is an example of the control file. You only need to copy-paste it in to an empty file called "control" and put it in the DEBIAN folder.
Package: ProgramName
Version: VERSION
Architecture: all
Maintainer: YOUR NAME <EMAIL>
Depends: python2.7, etc , etc,
Installed-Size: in_kb
Homepage: http://foo.com
Description: Here you can put a one line description. This is the short Description.
Here you put the long description, indented by 1 space.
If you want to build using dpkg -b <folder> you can use this program that will do everything with one command. If you regularly build packages, it is a pain to do all the stuff that I mentioned!
*The guide was taken from Basics of Debian Packages.
I'm using the trick "python -c 'import myscript.py'" to perform a syntax check on a script which uses 'import gtk'.
I get the following error when performing the syntax check, which implies that the gtk module is executing a check for the X display, even though all that's being done at this point is to import the module.
Traceback (most recent call last):
File "<stdin>", line 15, in ?
File "myscript.py", line 21, in ?
import gtk
File "/usr/src/build/463937-i386/install/usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py", line 37, in ?
RuntimeError: could not open display
Is there a way to avoid this error when performing the syntax check?
Before you ask - I'm not able to set $DISPLAY before the syntax check is run. The check is being run on remote servers as part of a distributed build system. These servers do not have an X display available.
Importing modules in Python executes their code!
Well-behaved modules use the if __name__ == '__main__' trick to avoid side effects, but they can still fail - as happened to you.
[BTW, getting to ImportError means the whole file already has correct syntax.]
If you just want to check syntax, without running at all:
python -m py_compile my_script.py
will check one file (and produce a .pyc as a side effect).
python -m compileall ./
will check a whole dir recursively.
python -c 'compile(open("myscript.py").read(), "myscript.py", "exec")'
avoids creating a .pyc.
But note that merely checking the syntax in Python catches very few bugs! Importing does catch more, e.g. mispelled names. For even better checks, use tools like Pychecker / Pyflakes.
What exactly do you mean by 'syntax checking'?
Can't you use a tool like pylint to check for syntax errors?
Otherwise: a very ugly (but probably possible hack):
In your python script detect whether X is present.
If it's not => use GTK on DirectFramebuffer (no X needed then). You'll need to compile GTK on DirectFB (and/or pygtk) from source (some pointers here).
If the remote machine has vncserver installed, you can have a dummy server running and connect to that. Sample instructions:
remotemachine $ vncserver -depth 16 -geometry 800x600 :7
New 'X' desktop is remotemachine:7
Starting applications specified in /home/user/.vnc/xstartup
Log file is /home/user/.vnc/userve:7.log
remotemachine $ DISPLAY=:7 python -c 'import myscript.py'
…
remotemachine $ vncserver -kill :7
Killing Xtightvnc process ID 32058
In your myscript.py, you could do like this
if __name__=="__main__":
import gtk
That will not execute gtk's __init__.py when you do "python -c 'import myscript.py'"
If you are editing with IDLE, Alt+X will check syntax of current file without running it.