Bug#960148: RFP: hstspreload -- Chromium HSTS Preload list as a Python package
Package: wnpp Severity: wishlist * Package name: hstspreload Version : 2020.5.5 Upstream Author : Seth Michael Larson * URL : https://github.com/sethmlarson/hstspreload * License : BSD-3 Programming Lang: Python Description : Chromium HSTS Preload list as a Python package It is used by httpx (althought it's not a hard requirement, but nice-to-have) Please consider package this under DPMT
Bug#960142: ITP: pyerfa -- Python bindings for ERFA routines
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org, debian-as...@lists.debian.org * Package name: pyerfa Version : TBD Upstream Author : Astropy Developers * URL : https://github.com/liberfa/pyerfa * License : BSD-3-Clause Programming Lang: Python Description : Python bindings for ERFA routines PyERFA is the Python wrapper for the ERFA library (Essential Routines for Fundamental Astronomy), a C library containing key algorithms for astronomy, which is based on the SOFA library published by the International Astronomical Union (IAU). All C routines are wrapped as Numpy universal functions, so that they can be called with scalar or array inputs. The project is a split of astropy._erfa module, developed in the context of Astropy project, into a standalone package, and therefore will be a dependency of upcoming Astropy releases. The packages will be maintained under Debian Astro team maintainance, with the repository at https://salsa.debian.org/debian-astro-team/pyerfa Best regards Ole
Re: Best practice on how to package a python module along with a c++ program
>> I'm packaging a c++ program (horizon-eda) which also contains a >> python module written in c++. Upstream's Makefile has a target 'pymodule' >> and 'make pymodule' creates horizon.so in the build directory. >> According to upstream this has to be copied Ń–nto python's sys.path > > The preferred mechanism would be to install the .so file into: > > usr/lib/python3.X/dist-packages/ (where X is the python3 version you are > building with) "horizon.so" isn't multi-arch safe, so please ensure it gets a suitable filename on installation. All CPython modules I can find on my system use one of these forms: /usr/lib/python3/dist-packages/package.cpython-38-x86_64-linux-gnu.so /usr/lib/python3/dist-packages/package/module.cpython-38-x86_64-linux-gnu.so /usr/lib/python3.8/dist-packages/package/module.cpython-38-x86_64-linux-gnu.so I assume this would normally be done by distutils, or is it handled by dh_python3 automatically?
