Seems the PyInstaller put all the python script into the executable file, and when run this file, it start PyInstaller bootloader first, then prepare a temp python environment add run the scripts.
So I wonder whether my source code are safe. Can I get the source code from the package when running the executable file?
PyInstaller includes the byte compiled (.pyc) files of your program but not the original source (.py) files. You don't even need to run the executable to get the .pyc files. There are more or less working Python decompilers that turn compiled byte code (.pyc) into equivalent source code (.py).
You need to assess whether this protection is good enough for your purposes. However as a friendly suggestion, I recommend first inventing/writing something that people will want to copy before worrying about how to protect it.
Related
I am a absolute beginner with Python. What I have done so far is I have installed Python with IDLE, Pycharm, Pygame-zero and Pyinstaller too. I have a (.py) file game I would like to turn into a (.exe) file. So I can release my game for my friends to play.
I have entered this command into CMD window "pyinstaller --onefile -w gamename.py"* (*My game is not really called "gamename". I have called it that in this code above. For this example only.)
When in the file folder of my game and then Pyinstaller converts my file into the (.exe) file. But everytime I try to run this file. It fails with this error message - "Fatal Error Detected, Failed To Execute Script Error".
I have watched all kinds of YouTube videos trying to solve this problem and have tried these following fixes:
Updated Pyinstaller (4.3).
Updated Python (3.9.5).
Changed the path in Enviroment Variables to point to Python39\Scripts and resetting my computer.
Coverted the (.py) file to (.exe) by including the console window. Then after running the program after when the console window disappears. Opening the CMD window again and typing the file directly "gamename.exe" to run.
Installing auto-py-to-exe program.
Each time deleting the Main, Dis and Spec files and moving the (.exe) file into the main file folder. With the resources for the games. Music, Images and Sounds.
Testing out my Python script to check. If it doesn't have any errors while loading through IDLE and it doesn't. It works straight away, I can play my game through IDLE. There is no errors in the code of my game script.
And after trying all of these solutions it still hasn't solved this issue.I still have the same error message appearing when trying to run my game. Now I have found out what the meaning is to this error message that appears. Which is:
"Fatal Error: failed to execute
This means something has gone wrong as it's giving you a visual warning about it; this is not an error, it's a warning; the real error has been printed to stdout/stderr. If you open the executable using the terminal or something else that will preserve the console output, you will most likely see a Python error telling you what went wrong. Fixing this and repackaging is the solution to this issue".
I have remade the (.exe) file including the console window and it does explan what the error is. When I try to run my game, the error comes up as:
"FileNotFoundError: {Errno 2} No such file or directory: C:*****\Local\Temp_MEI58602\pgzero\data\icon.png {4268} Failed to execute script.
Any suggestions? On how to fix this error please. So I can run and play my game outside of Python on any PC.
A Possible Answer:
I have found a webpage that has the possible answer to my problem. But I don't know what they mean, because I am a beginner with Python. Can anybody read this and break it down for me? Here is what it say's:
"Pyinstaller packaging exe, missing icons and other issues
Reason
When the exe runs, it will decompress a resource folder named "_MEI*" to a temporary directory on the computer, and delete it when the program ends.
uses a path like ‘\icon.png’ in the program. When the exe is running, it will only search for its own directory, of course it cannot be found.
Two, the solution
Make sure the picture is in this temporary resource folder
This can be done by editing the'.spec' configuration file to add pictures.
(Note: .spec is the file generated by Pyinstaller last time, in your python project directory.)
These are the three pictures I used, which is actually adding three tuples to the "binaries" list
Before the comma is the address of the picture in the python project, after the comma is the address of the package into the ‘_MEI*’ temporary folder.
I have built an ‘img’ folder to store pictures in it. Just put a dot in the root directory, such as (’./img/info.png’,’.’)
Finally, run when packagingpyinstaller program entry.spec, You can add the picture resource.
(Note: Other external resources can also be added in this way, such as .ini, .txt, .exe, etc.)
Make sure the program can find this path
Because the name of the temporary directory is different each time, a method is needed to dynamically obtain this path.
The code is presented, and the core statement is ‘os.path.realpath(sys.path[0])’.
Python running effect is as follows:
Package it as an exe, drag it to the cmd window and run it."
Here is the link to the webpage to the article. Because it makes use of screenshots that I can't include on this webpage;
(https://www.programmersought.com/article/94965073850/)
Please read this acticle and break it down for me. It does seem to be explaining the solution to my problem. But what does it all mean? What pictures is he talking about? Please explain.
I am not sure why but PyInstaller doesn't seem to bundle everything needed for Pygame Zero, including that icon.png file. The solution is simple, though. You just need to use pyinstaller --collect-all pgzero --onefile -w <scipt_name>. If your game has sounds, images or anything like that, remember to include those specific folders as well using --add-data <file_or_folder>. Also, make sure your script includes the following lines.
import pgzrun
# GAME CODE HERE
pgzrun.go()
I hope it helps, even though it is a little late.
I am in the process of developing an R package with external source code that takes a long time to compile. While compilation time isn't a big problem for a one-off installation, I have to routinely reinstall the package to test new additions. Is it possible to prevent re-compiling the source code if there haven't been any changes to it?
I don't necessarily need this to be automated, but I can't figure out a manual solution either. As my source code is in Rust, the following serves as the most representative example I have (note that it requires Rust cargo to be installed):
git clone https://github.com/r-rust/hellorust
Rscript -e "devtools::install('hellorust', quick = TRUE)"
When I run the above, I see that the hellorust.so file has been created in the src directory, but how do I make devtools::install() use this file rather than recompile everything? It doesn't seem like devtools::install(quick = TRUE) or devtools::install(build = FALSE) are meant for this...
Alternatively, is it possible to achieve the desired behavior on the Rust side of things? I don't understand why cargo would recompile everything if there haven't been any changes and the target directory is still there. That said, I'm quite new to Rust and compiled languages in general so my understanding of the broader concepts involved here is unfortunately quite limited...
I would also be interested to learn if there is a better way to test R packages during development than manually reinstalling them.
Based on the comments by r2evans, the final answer seems to be that this isn't what devtools::install is for.
As per the devtools documentation, there are three main tools for "frequent development tasks":
load_all
document
test
Of these load_all "simulates installing and reloading your package, loading R code in R/, compiled shared objects in src/ and data files in data/". By default, load_all() will not recompile source code in src/ (unless the recompile flag is set to true).
So the answer is to use load_all as opposed to install during package development and manually control when to compile the source code using something like devtools::compile_dll.
I look at the source code of file and see
I run file script and see
ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
I recall that I have been able to read this binary as plain text sometimes and saw that it is filesystem dependent script.
However, I forgot how I did it.
The script is just splitting a file and just interested in what is the split pattern what it is using.
However, with those ^# signs it is difficult to make sense of it.
However, there are rather much text which you can read.
How can you visualize such a binary file better?
I would suggest to use the strings command:
strings script | less
Note that despite its name, script is not a script but a binary executable, as file shows.
I made a small application using Python and Tkinter and I then tried to convert it into an executable file using Pyinstaller.
Pyinstaller creates the executable in the folder 'dist' as expected but when I double click on the file it will not run. Can you please help me find out what I am missing?
When this happens to me.. I use the process of elimination to discover the cause.
Simply remove modules from your code until the program execution actually begins. You can detect if you code is running by putting a dbgview output statement at the top of your code. Once your code execution works... you'll know what module or section of code is the root of the problem with regard to pyinstaller.
On windows after running the grunt build command for creating brackets shell it gives done without errors but i dont see any .exe file generated..
What might be the problem???
Here are some possible solutions:
Are you following the full brackets-shell build instructions, including all prerequisites?
Make sure Brackets isn't running at the same time. The build will fail silently if the .exe file is currently in use (see bug).
Try with a fresh git clone of the repo. If your brackets-shell local copy has been around for a while, sometimes the build & deps folders can get in a bad state. (I'm assuming you haven't modified the source at all. If you have, try with an unmodified copy of the source first to make sure it builds correctly without any of your changes).
Check that python --version shows 2.7.x
Verbose build output would also be helpful in diagnosing issues like this, but unfortunately there's not yet an easy way to get that...
If you follow the instructions on bracket-shell's wiki page, the Windows executable should be created in the Release directory.