Debian packaging of Python code - python

I am trying to create a debian package of my Python code, but I am very confused about some fields in debian/control files. Namely, what
X-Python-Version, XS-Python-Version and XB-Python-Version stands for?
Thanks in advance.

It is described here: https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
The optional X-Python-Version (preferred) or XS-Python-Version field in the general paragraph (the first one, for the source package) of debian/control specifies the versions of Python (not versions of Python 3) supported by the source package. Similarly, X-Python3-Version is used to specify the versions of Python 3 supported by the package.
The use of XB-Python-Version in the binary package paragraphs of debian/control file has been deprecated and should be removed
So you should only use X-Python-Version and perhaps X-Python3-Version.
To specify what version of Python is required to build your package, you want Build-Depends as described here: https://www.debian.org/doc/packaging-manuals/python-policy/ap-build_dependencies.html
For example:
Build-Depends: python (>= 2.6.6-9)

Related

Is there a way to specify minimum python version requirement for my script since pipfile does not support this?

Is there a way to specify minimum python version requirement for my script ? For example my script requires python 3.6+ because it uses f-string. I have test my script under 3.7, 3.8, 3.9, they all work.
But since pipfile doesn't support minimum version, refer to pipenv specify minimum version of python in pipfile? and this open issue https://github.com/pypa/pipfile/issues/87
So is there a way to do that ? Now I just write it in readme.
--- update ---
https://github.com/pypa/pipenv/issues/2683 indeed said
Note that the python_version key is optional. You can always remove it
if it causes problems, and document the version requirements otherwise
(i.e. in the README).
Check this post. This may do what you require:
#!/usr/bin/env python
import sys
if sys.version_info[0] != 3 or sys.version_info[1] < 6:
print("This script requires Python version 3.6")
sys.exit(1)
# rest of script, including real initial imports, here

Programmatically check if wheel is compatible with Python installation

Is it possible to programmatically check if a wheel (whl) is compatible with the chosen Python installation before attempting to install?
I'm making an automated packages installer (packages needed for my Python project to work), and I need to only attempt to install compatible pkgs, so if there are errors, I know they are only from the compatible modules and I should see what happened (not errors also from incompatible pkgs, which I wouldn't care). Example: I'd have wheels for Python 3.5 and 3.7, and in a 3.5 installation, 3.7 wheels could not be tried to be installed.
I've tried pkginfo (https://pypi.org/project/pkginfo/), but on wheel.supported_platforms, it returns an empty array and I can't do anything with that (a wheel with "any" or with "win32" on their name in the platform part, returned an empty array, so I can't use that, it seems).
Also tried the output from python -m pip debug --verbose, but the following appears:
WARNING: This command is only meant for debugging. Do not use this with automation for parsing and getting these details, since the output and options of this command may change without no
tice.
This makes the command not possible to use, even though bellow that it prints the "Compatible tags", which more or less I could use to determine if a wheel is supported or not from its name. Example of those "Compatible tags" in a Python array:
['cp39-cp39-win_amd64', 'cp39-abi3-win_amd64', 'cp39-none-win_amd64', 'cp38-abi3-win_amd64', 'cp37-abi3-win_amd64', 'cp36-abi3-win_amd64', 'cp35-abi3-win_amd64', 'cp34-abi3-win_amd64', 'cp
33-abi3-win_amd64', 'cp32-abi3-win_amd64', 'py39-none-win_amd64', 'py3-none-win_amd64', 'py38-none-win_amd64', 'py37-none-win_amd64', 'py36-none-win_amd64', 'py35-none-win_amd64', 'py34-no
ne-win_amd64', 'py33-none-win_amd64', 'py32-none-win_amd64', 'py31-none-win_amd64', 'py30-none-win_amd64', 'cp39-none-any', 'py39-none-any', 'py3-none-any', 'py38-none-any', 'py37-none-any
', 'py36-none-any', 'py35-none-any', 'py34-none-any', 'py33-none-any', 'py32-none-any', 'py31-none-any', 'py30-none-any']
With, for example, "pyHook-1.5.1-cp36-cp36m-win32.whl", I could check the name and see if it's compatible or not (except because of the warning above...).
Any other ideas?
Thanks in advance for any help!
EDIT: I could go manually and pull things from the name and hard-code the some possibilities I see on documentation, like "win32" and "win_amd64" (as I did before), but then I'd need to know exactly all the possibilities that the parts of the name can have (I saw a cool expression on the documentation: "e.g." - which means there are more than the mentioned things) and have a lot of work on that. I was hoping there was already someone that had made such thing (maybe even Python itself has some way in any of its internal packages).
You can do this using packaging.
pip install packaging
An example code to get the tags similar to how you got from pip would be:
from packaging.tags import sys_tags
tags = sys_tags()
print([str(tag) for tag in tags])
# ['cp39-cp39-manylinux_2_33_x86_64', 'cp39-cp39-manylinux_2_32_x86_64', 'cp39-cp39-manylinux_2_31_x86_64', ..... , 'py31-none-any', 'py30-none-any']
Of course, you can do much more things programmatically with the above variable tags:
>>> tags = sys_tags()
>>> for tag in list(tags)[:3]:
... print(tag.interpreter, tag.abi, tag.platform)
...
cp39 cp39 manylinux_2_33_x86_64
cp39 cp39 manylinux_2_32_x86_64
cp39 cp39 manylinux_2_31_x86_64
For more in-depth documentation, check: https://packaging.pypa.io/en/latest/tags.html#packaging.tags.sys_tags

Signature method in Inspect module for python 2

I am trying to run a Python 3 library in Python 2. It uses inspect module and signature method which is not implemented in Python 2 version of the module.
signature = inspect.signature(initializer)
There is no implementation in __future__ that can help (at least, I haven't found one).
How can I replace this method?
Package funcsigs on PyPI is a backport of PEP-362 (which adds signature introspection) to Python 2.6+. So change the line in question to
import funcsigs
signature = funcsigs.signature(initializer)
inspect2 is backport of the entire Python 3.6 inspect module to Python 2.7. Like funcsigs it is also available from PyPI, and inspect2 is more recently maintained. (As I'm writing this, inspect2 was last updated in 2019, while funcsigs was last updated in 2016.)

Define Python version inside project

Many times I work on other developers' projects. I need to detect the Python version they used and sometimes it is hard to find.
I want to define which interpreter version I am using inside my project so that future developers will know which one to use.
Is there any standard (acceptable) way to do it, is it README.md?
pyenv has the .python-version file which can be created with:
pyenv local 3.8.0
and enabled by users with:
pyenv local
In Python Poetry you can add to your pyproject.toml:
[tool.poetry.dependencies]
python = "~2.7 || ^3.2" # Compatible python versions must be declared here
Best option I found and using it is inside the README.md file:
# Requirements
* Python (2.7.13)
I do not know if there is a standard convention, but for development repositories I have created I add a __python_version__ special attribute along with the __author__ and other attributes at the top. This way it is simple and quick to call when you import the package (no searching strings or readmes), and consistent.
import x as y
y.__python_version__

Where can I obtain Autohotkey.dll library to run Pyahk?

Pyahk documentation says:
A copy of the ANSI 32-bit dll must be provided either in the system location of your version of Windows, or in the same folder as the ahk.py file. (The required dll is not provided as part of this distribution, see the AutoHotKey.dll site for download instructions (alternate link AutoHotKey_H).)
Autohotkey.dll site does not provide any download instructions. The alternate link does not work.
I found some dlls here. Pyahk is not able to import the 32bit dll versions. I'm able to import ahk in python without the missing dll warning with the 64bit dll, but upon a call the library complains about some chinese characters.
Possibly I need to compile autohotkey.dll myself. If so I would prefer a method which does not require me to install a ton of compilation tools.
You can find the source code here: https://github.com/HotKeyIt/ahkdll
And the releases can be found here: https://github.com/HotKeyIt/ahkdll-v1-release
You'll find a couple of different versions (unicode, ansi, 64 bit, 32 bit ...).

Categories