mikepurvis/catkin_tools_python

Experimental plugin for catkin tools to allow building plain Python packages.

catkin_tools_python's Issues

Should pass --no-deps to setup.py

cppx should walk the workspace rather than just checking top level directories.

When not installing, use "develop" rather than "install".

cppx should have an option to force overwrite

Generated package.xml files should propagate dependency info

Not sure this how necessary this is, since all python dependencies are effectively exec_depend. Also, there isn't really a good way of getting this info:

http://stackoverflow.com/questions/24236266/how-to-extract-dependencies-information-from-a-setup-py

README should have end-to-end usage example

Issue with rebuilding

Happens on Ubuntu/Debian:

    os.rename(source_path, dest_path)
OSError: [Errno 39] Directory not empty

Stage `debian-fix` failed with arguments:
  source_path: ...... install/lib/python2.7/site-packages
  dest_path: ...... install/lib/python2.7/dist-packages

Do we have to rely on PKG-INFO ?

After trying it out, I realized that create_python_package_xmls extracts information from PKG-INFO.

I see two potential issues with this strategy :

• In a workspace, I can checkout a (python) repo, and try to build it (to get my ros/catkin package to
  depend on it for example). But many python repo do not include PKG-INFO ( they are not the output of sdist ).

• After releasing with bloom, the release repo doesn't have a PKG-INFO, which means one cannot generate package.xml on the fly when building a deb package. => A package.xml need to be maintained in the release repo for a thirdparty package

So I am wondering if there would be another place where we could extract information from ?
Or is there a way I could fix the issues I listed previously ?

My current flow to mutate a pip package into a ros package with catkin_pip is :

• getting the source of the package (as in upstream, not the sdist output),
• bloom releasing that,
• CMakeLists and package.xml are patches in the release repo, and get automatically added.
• rosdistro PR for the buildfarm to make the package.

Does this mean I should change that workflow to be able to get the PKG-INFO and automatically generate the package.xml in the release repo ? I am trying to minimize maintenance on the release repo.