We have a package (rebound) up on PyPI that includes a C extension . The relevant part of the setup.py file looks like this (simplified):
libreboundmodule = Extension('librebound',
sources = [ 'src/rebound.c'],
include_dirs = ['src'],)
Additional libraries need access to rebound.h, but when one runs
pip install rebound
it doesn't install rebound.h anywhere. How can we get distutils/setuptools to install rebound.h somewhere along with all the python modules? We're hoping that we can have pip install rebound do all the work so the user doesn't have to run any additional commands.
Related
Last time I've followed recommended src layout (https://hynek.me/articles/testing-packaging/) with using tox with great success.
However VSCODE tests discovery fails because src package cannot be imported. That is expected as we want to test installed package.
But how to debug my tests in vscode?
(Q author here: I've done research on that before posting the question, so sharing what I found)
Not solution
You could modify your PYTHONPATH to point to your src directory, but it breaks the main benefit from having separate src directory (read the link from OP).
Solution
Use pip install -e path/to/your/package (usually pip install -e .) to enable development mode and test versus your codebase as it would be installed.
After that your tests should be discovered properly. Otherwise it is different issue - read vs code OUTPUT console.
Note: this requires setup.py as a build backend
workaround for poetry
pyproject.toml
[build-system]
requires = [
"poetry-core>=1.0.0",
"setuptools" # to support local installations
]
then
poetry build --format sdist && tar --wildcards -xvf dist/*.tar.gz -O '*/setup.py' > setup.py
pip install -e .
Source: https://github.com/python-poetry/poetry/issues/34
TLDR: proper solution is outside of poetry scope, links to python-list discussions: https://github.com/python-poetry/poetry/issues/34#issuecomment-732478605
I'm trying to deploy a Cython wrapped C++ module to PyPI as wheel. The goal is to make I2C hardware modules work with Python on any Raspberry Pi. So far I compiled the code and I know it works if I just copy compiled module from Pi 3B running Buster to Pi Zero W running Stretch, but when I deploy the wheel to test.pypi.org from Buster and try to install it on Stretch I get:
Could not find a version that satisfies the requirement pyiArduinoI2Crelay (from versions: )
No matching distribution found for pyiArduinoI2Crelay
If I merely rename the wheel from *_armv7l.whl to *_armv6l.whl
module downloads and works on Pi Zero. But Pi 3B downloads previous version from PyPI (and i used --no-cache-dir and rm -r .cache/pip/)
If I do sdist and upload it complains about not having Cython installed upon installation of the module, although I know for a fact that it is installed, because it's the same Pi I compiled wheels before. (setup_requires and install_requires dont's seem to work)
So far none of these helped:
https://www.python.org/dev/peps/pep-0425/#platform-tag
https://packaging.python.org/guides/distributing-packages-using-setuptools/#platform-wheels
https://wheel.readthedocs.io/en/stable/user_guide.html#building-wheels
Prepare C-based Cython package to publish on pypi
Here's the link to the project:
https://github.com/tremaru/pyiArduinoI2Crelay
Here's the setup.py:
from setuptools import setup
from distutils.extension import Extension
from Cython.Build import cythonize
from Cython.Distutils import build_ext
def readme():
with open('README.md') as readme:
return readme.read()
setup(name='pyiArduinoI2Crelay',
version='1.6.4.dev8',
description='iarduino.ru module for Raspberry Pi',
long_description=readme(),
classifiers=[
'Programming Language :: Python :: 3',
],
url='http://github.com/tremaru/pyiArduinoI2Crelay',
author='iarduino.ru',
author_email='shop#iarduino.ru',
license='MIT',
package=['pyiArduinoI2Crelay'],
ext_modules = [Extension(
name="pyiArduinoI2Crelay",
sources=["pyiArduinoI2Crelay/pyiArduinoI2Crelay.cpp"])],
include_package_data=True,
python_requires='>=3',
setup_requires=['Cython'],
install_requires=['Cython'],
cmdclass = {
"build_ext": build_ext
}
)
I want to be able to publish one version of the module for all Raspberries. So, is there a way to pack multiple .so's to one wheel? Or maybe some kind of manylinux1 tag for arm architecture?
Turns out I'm a knucklehead. I didn't need any Cython stuff in my setup after generating cpp file. All I needed to do is remove Cython stuff and remove cmdclass = { "build_ext": build_ext }. And then in publishes and builds as source distribution no problem.
I am migrating the configurations from setup.py to setup.cfg but I have a problem with cmdclass keyword. I looked into setuptools docs and it seems like this keyword is not documented or supported. So I tried options.entry_points instead. But I keep getting invalid command error.
Here is what I have:
setup.cfg
[options.entry_points]
console_scripts =
install = CustomInstall:run
and
setup.py
from setuptools.command.install import install
from setuptools import setup
class CustomInstall(install):
def run(self):
print('overriden install command')
setup()
The result was just a normal install command. However, I would like to replicate the behaviour that I get when I run:
# setup.py
from setuptools.command.install import install
from setuptools import setup
class CustomInstall(install):
def run(self):
print('overriden install command')
setup(cmdclass= {"install": CustomInstall})
which gives an overriden install command.
I don't believe it's possible. Leave it in the setup.py.
It is not supported.
See this PR for more information.
The cmdclass keyword in setup.cfg has been fixed in v54. It is still not documented though.
Now you can do:
setup.cfg (only part)
[options]
cmdclass =
install = build.MyInstall
build.py
from setuptools.command.install import install
class MyInstall(install):
def run(self):
print("Custom install start")
super().run()
print("Custom install done")
Both files are located in the root of project.
When you run python setup.py install, the custom install script gets triggered. This setup is equivalent to the setup(cmdclass=...) you used.
What [options.entry_points] and console_scripts does is create shell commands which run specific functions in your code base. These commands will work once your package has been installed in an environment.
So in your example, a new shell command install would be created, and it would run the run() function from a package called CustomInstall.
Based on looking at source code, I would guess the correct syntax is instead:
[global]
commands =
install = mypackage.CustomInstall
but I haven't been able to make it work either yet.
ruamel.yaml seems to require PIP to install, which is not the default buildroot solution to build and install a Python package.
Is is possible to -at least- install a pure Python version of ruamel.yaml into a buildroot image - and how to circumvent the pip limitation?
Is is possible to cross-build ruamel.yaml?
Forcing RUAMEL_NO_PIP_INSTALL_CHECK env. var. does not help:
test compiling test_ruamel_yaml
running install
Checking .pth file support in ...
Failed to import the site module
ModuleNotFoundError: No module named '_sysconfigdata_m_linux_arm-linux-gnueabihf'
error: command '.../output/host/bin/python' failed with exit status 1
package/pkg-generic.mk:310: recipe for target '.../output/build/python-ruamel-yaml-0.15.45/.stamp_target_installed' failed
ruamel.yaml indeed requires pip to install from PyPI (using the .tar.gz or a .whl appropriate for your platform), this is documented.
The reason for this is that the fixes necessary to enable nested package installs where only implemented for pip (and not for easy_install or python setup.py installs).
That however does not preclude you from using ruamel.yaml, especially if you don't need the C extension (which is checked for at load time).
You can either check out a tagged version from bitbucket or untar a .tar.gz from PyPI and move the result to your site-packages directory:
$ virtualenv /tmp/ruamel_yaml_no_pip
Using base prefix '/opt/python/3.7'
New python executable in /tmp/ruamel_yaml_no_pip/bin/python
Installing setuptools, pip, wheel...done.
$ cd /tmp/ruamel_yaml_no_pip/
$ source bin/activate
(ruamel_yaml_no_pip) $ mkdir lib/python3.7/site-packages/ruamel/
(ruamel_yaml_no_pip) $ touch lib/python3.7/site-packages/ruamel/__init__.py
(ruamel_yaml_no_pip) $ wget -q https://files.pythonhosted.org/packages/63/a5/dba37230d6cf51f4cc19a486faf0f06871d9e87d25df0171b3225d20fc68/ruamel.yaml-0.15.45.tar.gz
(ruamel_yaml_no_pip) $ python -m ruamel.yaml
/tmp/ruamel_yaml_no_pip/bin/python: Error while finding module specification for 'ruamel.yaml' (ModuleNotFoundError: No module named 'ruamel')
(ruamel_yaml_no_pip) $ tar xf ruamel.yaml-0.15.45.tar.gz
(ruamel_yaml_no_pip) $ mv ruamel.yaml-0.15.45 lib/python3.7/site-packages/ruamel/yaml
(ruamel_yaml_no_pip) $ python -c 'from ruamel.yaml import YAML; print(YAML().load("{hello: world}")["hello"])'
world
(ruamel_yaml_no_pip)
(ruamel_yaml_no_pip) $ python -c 'from ruamel.yaml import __with_libyaml__ as X; print(X)'
False
(The URL is copied from the 0.15.45 project download page)
For development I normally just make a soft link from a virtualenv's site-packages to my ruamel directory.
I don't know how and if that translates to a buildroot environment (if so please publish your result).
I overlooked the buildroot documentation.
There is a critical parameter to define: SETUP_TYPE = setuptools rather than SETUP_TYPE = distutils.
With the following snippet:
PYTHON_RUAMEL_YAML_VERSION = 0.15.45
PYTHON_RUAMEL_YAML_SOURCE = ruamel.yaml-$(PYTHON_RUAMEL_YAML_VERSION).tar.gz
PYTHON_RUAMEL_YAML_SITE = https://pypi.python.org/packages/63/a5/dba37230d6cf51f4cc19a486faf0f06871d9e87d25df0171b3225d20fc68
PYTHON_RUAMEL_YAML_SETUP_TYPE = setuptools
PYTHON_RUAMEL_YAML_LICENSE = MIT
PYTHON_RUAMEL_YAML_LICENSE_FILES = LICENSE
PYTHON_RUAMEL_YAML_ENV += RUAMEL_NO_PIP_INSTALL_CHECK=1
$(eval $(python-package))
ruamel.yaml installs perfectly on the target image.
You can cd to YOUR_ENV/lib/pythonxx/site-packages/ and have a look, but is there any convenient ways?
pip freeze list all the packages installed including the system environment's.
You can list only packages in the virtualenv by
pip freeze --local
or
pip list --local.
This option works irrespective of whether you have global site packages visible in the virtualenv.
Note that restricting the virtualenv to not use global site packages isn't the answer to the problem, because the question is on how to separate the two lists, not how to constrain our workflow to fit limitations of tools.
Credits to #gvalkov's comment here. Cf. also pip issue 85.
Calling pip command inside a virtualenv should list the packages visible/available in the isolated environment. Make sure to use a recent version of virtualenv that uses option --no-site-packages by default. This way the purpose of using virtualenv is to create a python environment without access to packages installed in system python.
Next, make sure you use pip command provided inside the virtualenv (YOUR_ENV/bin/pip). Or just activate the virtualenv (source YOUR_ENV/bin/activate) as a convenient way to call the proper commands for python interpreter or pip
~/Projects$ virtualenv --version
1.9.1
~/Projects$ virtualenv -p /usr/bin/python2.7 demoenv2.7
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in demoenv2.7/bin/python2.7
Also creating executable in demoenv2.7/bin/python
Installing setuptools............................done.
Installing pip...............done.
~/Projects$ cd demoenv2.7/
~/Projects/demoenv2.7$ bin/pip freeze
wsgiref==0.1.2
~/Projects/demoenv2.7$ bin/pip install commandlineapp
Downloading/unpacking commandlineapp
Downloading CommandLineApp-3.0.7.tar.gz (142kB): 142kB downloaded
Running setup.py egg_info for package commandlineapp
Installing collected packages: commandlineapp
Running setup.py install for commandlineapp
Successfully installed commandlineapp
Cleaning up...
~/Projects/demoenv2.7$ bin/pip freeze
CommandLineApp==3.0.7
wsgiref==0.1.2
What's strange in my answer is that package 'wsgiref' is visible inside the virtualenv. Its from my system python. Currently I do not know why, but maybe it is different on your system.
In Python3
pip list
Empty venv is
Package Version
---------- -------
pip 19.2.3
setuptools 41.2.0
To create a new environment
python3 -m venv your_foldername_here
Activate
cd your_foldername_here
source bin/activate
Deactivate
deactivate
You can also stand in the folder and give the virtual environment a name/folder (python3 -m venv name_of_venv).
Venv is a subset of virtualenv that is shipped with Python after 3.3.
list out the installed packages in the virtualenv
step 1:
workon envname
step 2:
pip freeze
it will display the all installed packages and installed packages and versions
If you're still a bit confused about virtualenv you might not pick up how to combine the great tips from the answers by Ioannis and Sascha. I.e. this is the basic command you need:
/YOUR_ENV/bin/pip freeze --local
That can be easily used elsewhere. E.g. here is a convenient and complete answer, suited for getting all the local packages installed in all the environments you set up via virtualenvwrapper:
cd ${WORKON_HOME:-~/.virtualenvs}
for dir in *; do [ -d $dir ] && $dir/bin/pip freeze --local > /tmp/$dir.fl; done
more /tmp/*.fl
why don't you try pip list
Remember I'm using pip version 19.1 on python version 3.7.3
If you are using pip 19.0.3 and python 3.7.4. Then go for pip list command in your virtualenv. It will show all the installed packages with respective versions.
.venv/bin/pip freeze worked for me in bash.
In my case the flask version was only visible under so I had to go to
C:\Users\\AppData\Local\flask\venv\Scripts>pip freeze --local
Using python3 executable only, from:
Gitbash:
winpty my_venv_dir/bin/python -m pip freeze
Linux:
my_venv_dir/bin/python -m pip freeze