add config ini to ament_mypy site package

[Arnatious]

fixes issue @jacobperron pointed out in sros discussion by adding ini to MANIFEST.in

Signed-off-by: Ted Kern ted.kern@canonical.com

[jacobperron]

CI is failing :

--- stderr: ament_mypy
19:10:05 error: Error: setup script specifies an absolute path:
19:10:05 
19:10:05     /home/jenkins-agent/workspace/ci_linux/ws/build/ament_mypy/ament_mypy.egg-info/PKG-INFO
19:10:05 
19:10:05 setup() arguments must *always* be /-separated paths relative to the
19:10:05 setup.py directory, *never* absolute paths.

I'm not sure why.

[Arnatious]

That is weird, doesn't grok with the changes made.

[Arnatious]

The generation is handled automatically, and the path is provided as relative in the manifest, I'm not sure where this error is coming from.

writing manifest file '/home/jenkins-agent/workspace/ci_linux/ws/build/ament_mypy/ament_mypy.egg-info/SOURCES.txt'
reading manifest file '/home/jenkins-agent/workspace/ci_linux/ws/build/ament_mypy/ament_mypy.egg-info/SOURCES.txt'
error: Error: setup script specifies an absolute path:
reading manifest template 'MANIFEST.in'
writing manifest file '/home/jenkins-agent/workspace/ci_linux/ws/build/ament_mypy/ament_mypy.egg-info/SOURCES.txt'

copying ament_mypy/__init__.py -> /home/jenkins-agent/workspace/ci_linux/ws/build/ament_mypy/build/lib/ament_mypy

    /home/jenkins-agent/workspace/ci_linux/ws/build/ament_mypy/ament_mypy.egg-info/PKG-INFO

setup() arguments must *always* be /-separated paths relative to the
setup.py directory, *never* absolute paths.

[dirk-thomas]

Please use package_data instead of a MANIFEST.in file like in other packages, e.g.

ament_lint/ament_uncrustify/setup.py

Lines 9 to 11 in 31a522c

	package_data={'': [
	'configuration/ament_code_style.cfg',
	]},

[Arnatious]

Done. There a reason to prefer it/that it caused this issue? Documentation for modern python seems to prefer the MANIFEST.in method.

[dirk-thomas]

Interesting, I was under the impression of the opposite to be the case.

Atm no ROS 2 package uses a MANIFEST.in file. So I think it is good to keep the same pattern. If there is a good reason to change I am more than happy to do so if that is what is the recommended way. Please provide some references if you have them at hand.

[Arnatious]

@dirk-thomas

• Mentioned first on setuptools: https://setuptools.readthedocs.io/en/latest/setuptools.html#including-data-files
• Opinionated blog post/slideshow: https://blog.ionelmc.ro/presentations/packaging/#slide:15
• Possibly out of date article about sdist vs bdist (tested locally, both seem to work) http://blog.codekills.net/2011/07/15/lies,-more-lies-and-python-packaging-documentation-on--package_data-/
• PyPA official stance as of a month ago neither package_data or data_files get installed pypa/sampleproject#30 (comment)
• Stackoverflow opinion to the contrary circa 2014 (more recent/lower rated answers go the MANIFEST way) https://stackoverflow.com/questions/24347450/how-do-you-add-additional-files-to-a-wheel

[dirk-thomas]

The sampleproject is indeed a credible reference. I am open to transition to MANIFEST.in and include_package_data=True. It would need to be ensured that all our toolchains work fine with it (e.g. colcon, symlink installs, Debian packaging, if we want to apply this to distro-agnostic Python packages stdeb).