Package Details: python-catkin_pkg 0.3.8-1

Git Clone URL: https://aur.archlinux.org/python-catkin_pkg.git (read-only)
Package Base: python-catkin_pkg
Description: catkin package library
Upstream URL: http://wiki.ros.org/catkin_pkg
Licenses: BSD
Conflicts: python-catkin-pkg, python2-catkin_pkg
Provides: python-catkin-pkg
Submitter: kartikmohta
Maintainer: kartikmohta
Last Packager: kartikmohta
Votes: 7
Popularity: 0.145326
First Submitted: 2017-06-01 00:23
Last Updated: 2017-10-12 23:16

Latest Comments

de-vries commented on 2017-06-27 21:29

Having tools + modules with the python3 version and modules only with python2 is also an acceptable solution as far as I am concerned. But if you want to make everyone happy you should probably have 4 packages in total:
- python-catkin-pkg-modules and python2-catkin-pkg-modules with modules that can coexist
- python-catkin-pkg and python2-catkin-pkg with tools that conflict, where python2-catkin-pkg provides python-catkin-pkg.

I'd also replace the underscore in the package name with a dash. That seems to be more standard on Arch (and python-catkin_pkg-modules looks pretty ugly to me). It is also what ROS does when generating Debian packages.

To avoid dependency problems, the rosdep key for `python-catkin-pkg` should also be updated to include both python versions of the modules and a set of working tools (for examples: [python-catkin-pkg-modules, python2-catking-pkg-modules, python-catkin-pkg]). After all, we don't know if another package wants the command line tools or the python modules, or which version of the python modules.

Note that we've been running ROS with python3 at Delft Robotics (though we write our own code in C++, which probably sidesteps many python3 problems). If you want to discuss our experiences with that you can chat me up at freenode #ros (my nick is de-vri-es). I leave my client connected while I'm not watching IRC, so if you highlight me and stick around I will reply.

kartikmohta commented on 2017-06-27 20:12

I think at least for now, to avoid building and installing both Python 2 and 3 version when only wanting one of them, having separate PKGBUILDs seems like a better way. That would also solve the conflicting packages problem.

My short term goal is to be able to exclusively use Python 3 with ROS, so having tools only available for Python 2 doesn't seem very appealing to me. I agree this is a personal opinion which may not be what most of the people want, so I am willing to change if there are compelling arguments against this approach.

de-vries commented on 2017-06-27 19:31

to chip in: I maintain a private binary repository for the company I work at with ROS packages and some dependencies not available in the official Arch repos. It is very important to have both the python 2 and python 3 modules available. I've been contributing to ROS over time to improve python 3 compatibility and it has come a long way. However, there are still tools/packages that wont work with python 2. If you require users to choose between python 2 or python 3 modules that effectively blocks any possibility to transition to python 3.

For the repository I maintain, I use two PKGBUILDs, one for python2 which includes the tools, and one for python3 which has only the modules. Splitting in separate packages for modules and tools is even neater I suppose, but for me that wasn't a necessity. Do note that the name `python2-catkin-tools` as was suggested earlier (though I cant find the comment now) is not a good choice. `catkin_tools` is a different project providing different command line tools to work with caktin:
https://github.com/catkin/catkin_tools

Providing a python 2 tools package with modified executable names makes no sense to me. For the command line tools the choice of python 2 or 3 is arbitrary and should be invisible for the user. Python 2 might be more stable since that is what the rest of the ROS community uses. Python 3 is a bit more progressive and might help mature python 3 support.

wbthomason commented on 2017-06-27 14:57

I like @kartikmohta's solution or mine - they minimize the number of PKGBUILDs and the amount of package breakage that has to be dealt with, and doesn't preclude @squirrel's desired ability to switch from Python 2 to 3 (even one package at a time; you have all the files you need in place).

There is also precedent for appending 3 instead of 2; binaries like python3 or the like do this already.

squirrel commented on 2017-06-27 11:06

Interesting approach with appending 2 at the end, but making it otherway does not sound legit to me, because it's not standart way of solving this problem.

Reason for splitting modules and scripts, is that it's best course of action I can imagine for moving ros from python2 to python3 eventually. You can't possibly make the switch for all packages at once, so you inevitably end up in situation where part of the packages use python2 and part uses python3.

Which is exactly the situation where for a lot of packages, modules for both versions would be required.

I am voting for any solution that allows this in one way or the other, and I think that inevitably this should be possible for all packages that allow it. (Especially, because making this possible is just one enviromental variable)

This actually allows to switch from python2 to python3 by switching one package at a time, yeah it means managing both python2 and python3 versions, but I believe we can find a way how to manage that.

As for managing PKGBUILD files, I was thinking that maybe we can find a way how to have one 'source' PKGBUILD that would generate two PKGBUILD files, one for python2 and one for python3.

For example for this package, it's just that you write PKGBUILD for python2 version, and than "sed -i s/python2/python/g" it to get python3 version ?

(correct me if I am wrong)

P.S: I am present at #ros@freenode under nickname veverak or squirrel

kartikmohta commented on 2017-06-27 04:22

Another approach is to append a "2" to the end of the scripts for the Python 2 version. That seems to be the way it's done for all the packages in the official repos which have installed scripts (see https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-peewee, https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-igraph).
Or since ROS officially only supports Python 2 for now, append a "3" at the end of the Python 3 scripts.

wbthomason commented on 2017-06-26 20:46

I can post my modified PKGBUILD if this route seems like the right choice.

wbthomason commented on 2017-06-26 20:45

@kartikmohta @squirrel What if we just removed the scripts from one of the packages in the package() function of the PKGBUILD? This is what I did to allow myself to install both the Python 2 and 3 modules at once. It does feel a little bit hacky, and it would break the PKGBUILD if the script names or locations changed, so I'm not sure it's the best solution. However, it would let us keep both Python 2 and 3 in one package (as I think is desirable) and prevent the need to separate the modules and scripts (which would create even more packages to install and require a lot of ROS PKGBUILDs to be updated).

kartikmohta commented on 2017-06-26 19:37

@squirrel @wbthomason Yes agree that it is a problem for automated upgrades which I don't like either. Sadly there is no easy way to install only a single package from a PKGBUILD which creates multiple packages in Arch (let me know if you know any way). So, I think the only clean option is to have separate PKGBUILDs for Python 2 and 3 even though I would like to keep the more elegant (and easier to maintain) approach of having a single PKGBUILD provide both.
Also, I don't think we need to split out the modules and scripts, don't know of anybody who uses the modules outside of the ROS ecosystem.

yimingl commented on 2017-06-26 18:02

I guess I can choose one of the two to install after build but other other packages still depend on python-catkin-pkg (currently gone), did i do something wrong?

All comments