We're having a Python 2 product we publish as RPMs. The RPMs include only the pyo/pyc files, and the running scripts refer to certain pyo files to run the product. We use setuptools to package these RPM:
python setup.py bdist_rpm --release=... --requires=... --bdist-base=...
We're now porting out product to Python 3.6, and found that pyc files no longer reside in the same location as the py files. They are located in a __pycache__ folder under the folder of the py files, and moreover, they will not work if the corresponding py file does not exist. There is still support in legacy behavior if the pyc file is replacing the py file, and is not in __pycache__.
The documentation shows that the python compileall can accept a -b flag that:
Write the byte-code files to their legacy locations and names, which
may overwrite byte-code files created by another version of Python.
The default is to write files to their PEP 3147 locations and names,
which allows byte-code files from multiple versions of Python to
coexist.
However, since we use setuptools, we do not control the compilation command line.
Questions:
Is there a way to tell setuptools to compile the code with the -b flag and keep the legacy location of pyc files?
Is there a better way in Python 3 to publish source-less RPMs and still be able to call the pyc file from a script?
Related
I have a git repository of python scripts , which are stand alone scripts, but want to use pyinstaller to build these into executable's.
Is there a way to be able to have these compile so that each converted script doesn't have a copy of the modules and the python lib.so file but instead uses a shared directory as this would reduce the size of the generated script considerably.
I understand how to use use a crafted spec file to build all the scripts as separate files but I would like the resulting dist directory to have the scripts in a top level dir and all the .so *zip files in a sub directory to reduce confusion.
I'm new to packaging in Python. I've tried to specify my non-python files within setup.py's 'scripts' argument, and also specifying the file within MANIFEST.in, however after I package the file using python setup.py build sdist and install using pip, only the files with the .py extension make it to the site-packages/my_package directory.
Am I missing something?
15 minutes later I find the answer. sdist only includes the *.py files. I just changed the command to use bdist_wheel and all the files I needed were included.
I have run setup.py and installed, my script/package it all appears in Python27\Lib\site-packages in a folder with the relevant .egg.info file.
However, after adding site-packages to my PATH I cannot run the relevant scripts.
python: cant open file 'mypackage': [Errno 2] No such file or directory
What have I missed?
Essentially I would like to install the package, several modules are included in a folder with __init and __main files. Once installed I would like to just run
python mypackage inputfile.txt
however mypackage is not found. I will use optparse for taking in the txt files, but that is irrelevant as I can't get the packages installed.
As a rule, scripts do not go in site-packages. On the MS-windows platform they generally go in C:\Python27\Scripts\.
So on MS-Windows you probably want to add C:\Python27\;C:\Python27\Scripts\ to your $PATH.
Additionally, you have to associate the .py filetype with python.
In general, the whole chapter Using Python on Windows of the official CPython documentation should be considered required reading for users of Python on Windows.
I am using Windows 7 and have both Python 2.7.5 and 3.3.2 installed. My path environment variable is set as
C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\python27;C:\Python33\Scripts
When I import any Python module into another module a .pyc file is created. The place where it is created depends on whether Python2 is invoked or Python3 to run it.
when I double-click the module the .pyc file is created in the same directory
when I am editing via IDLE and then run it then the file is created in the subdirectory.
If I add #! Python3 at the top then double-clicking makes the .pyc file in the sub-directory.
I understand that the reason for this is because of difference in how Python2 and Python3 have decided to manage the byte-compiled codes.
I am currently focusing on Python3 and want the files to be created in subdirectory only.
I tried editing the path variable to place Python3 before Python 2 so that Python3 should be invoked instead of Python2. Even after changing it when I double-click the Python script that didn't happen and the byte-compiled code was created in the same directory.
So Python2 was used to run the Python script on double-clicking. What is causing this behaviour and how can I make sure that Python3 is invoked instead of Python2 without uninstalling Python2?
Python 3 has changed how the bytecode (.pyc) files are stored. Python 2 uses the convention of putting them in the same directory, but for Python 3 the developers decided to reduce clutter by putting them all in a separate directory. This also made support for Python implementations other than CPython easier, as each implementation could have its own .pyc files in the __pycache__ directory rather than overwriting those from other implementations.
I want to add Python as a scripting language to my game. If instead of distributing PY script, I distribute the PYC compiled files with my game, will the user still need Python installed, or will the DLL be sufficient?
Not only would they still need the Python interpreter, but the compiled python byte-code files are not guaranteed to work across different platforms.
You do need an executable to actually load the files into the VM. Fortunately it doesn't need to be very complex.
pyinstaller can be used to convert the .py file into an executable file
to install the pyinstaller
pip install pyinstaller
and to convert the .py file let's say file.py
pyinstaller file.py
this will make two new folders in the same directory
build and dist. dist folder contains all the required dll and file.exe to run the python code without python installed.