Package Details: python-catkin_pkg 0.4.24-2

Git Clone URL: https://aur.archlinux.org/python-catkin_pkg.git (read-only, click to copy)
Package Base: python-catkin_pkg
Description: Standalone Python library for the catkin package system
Upstream URL: https://github.com/ros-infrastructure/catkin_pkg
Licenses: BSD
Conflicts: python-catkin-pkg, python2-catkin_pkg
Provides: python-catkin-pkg
Submitter: kartikmohta
Maintainer: kartikmohta (bionade24)
Last Packager: kartikmohta
Votes: 11
Popularity: 1.37
First Submitted: 2017-06-01 00:23 (UTC)
Last Updated: 2022-01-22 05:27 (UTC)

Latest Comments

de-vries commented on 2017-06-27 21:29 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2017-06-27 14:58 (UTC) by wbthomason)

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 (UTC)

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 (UTC) (edited on 2017-06-27 04:30 (UTC) by kartikmohta)

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 (UTC)

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

wbthomason commented on 2017-06-26 20:45 (UTC)

@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 (UTC)

@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 (UTC)

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?

wbthomason commented on 2017-06-26 15:59 (UTC)

I strongly agree with @squirrel that this is a problem, and am also willing to help fix it.

squirrel commented on 2017-06-26 09:19 (UTC)

I think it's a problem, because it completely blocks using any automated way of installing packages, and unless it's easy to install nobody will update frequently.... and this approach is really bad considering we are speaking of ROS that has hundreds of packages, if each package would do that, you would definetly avoid using that mechanism.... What I described was 'simplest' approach - python2 version provides modules and binaries, python3 version provides only modules. That means that you _have_ to install python2 version and _can_ install python3 version. If we want trully correct way, best approach is to split modules and scripts into separate packages for both versions, like it's done for debian packages as seen in this debian recipe: https://github.com/ros-infrastructure/catkin_pkg/blob/master/stdeb.cfg what I have in mind is: python{,2}-catkin_pkg_modules -> just the modules, no conflict with each other python{,2}-catkin_pkg -> just the scripts, without modules, these depends on _modules version and conflicts with each other this way we should be able to get one step closer to ros with python3 in case we are able to do this for every package. P.S: I am more than willing to help with this

kartikmohta commented on 2017-06-25 16:31 (UTC)

@squirrel Yes agreed that an automated install (makepkg -i) doesn't work with the current PKGBUILD but you can choose to install any one of the two packages after building, right? Disabling the installation of the python scripts for the python3 package doesn't seem like the right solution since that requires you to install both versions to get the full functionality. I can just give in and create separate PKGBUILDs for the Python2 and Python3 version if the "manually choose the version to install" process is a big pain for people.

squirrel commented on 2017-06-25 15:19 (UTC) (edited on 2017-06-25 15:28 (UTC) by squirrel)

OK, I just realized that most of the packages are broken, which is current state: you wrote PKGBUILDs in way that two packages are builded, installed that conflict each other... why? that's wrong way of using AUR... Most of the packages I encountered support SKIP_PYTHON_SCRIPTS=1 enviromental variable, which enforces installation only of modules of that package (which does not conflict between python versions). I suggest setting that for every python3 version of package and getting rid of that god dam dependency confliction. EDIT: sent patch via email to owner of the package

squirrel commented on 2017-06-25 13:33 (UTC)

Hmm, last version of PKGBUILD builds two packages that conflict with each other, is that intented?

kartikmohta commented on 2017-06-21 19:27 (UTC)

For ROS, you'll mostly want to install the python2 package. Making ROS work with Python 3 currently is a pain.

racko commented on 2017-06-21 18:04 (UTC)

@osjacky430: You only want to install one of both. Apparently you already have one installed. Try continuing to install ROS with the one you have. If your package manager tells you that you need the other, uninstall the one you have and install the other ;)

osjacky430 commented on 2017-06-19 02:36 (UTC)

Sorry, kartikmohta, I'm a newbie and accidentaly send the delete request, and don't know how to cancel the request. I'm so sorry about it. :( However, during installation, error occurs as follow: python-catkin_pkg and python2-catkin_pkg are in conflict I could'nt find soultion so far, please help me with this, thanks in advance.

de-vries commented on 2016-03-16 19:37 (UTC)

It is currently not possible to install python 2 and 3 versions of catkin_pkg, which is somewhat annoying. It makes sense that you can only install the tools in /usr/bin once, but for the python library there is really no reason. Would it be an idea to split this into python-libcatkin-pkg and python-catkin-pkg, and do the same for python2? Alternative names could be: python-caktin-pkg (libs only) python-caktin-pkg-tools (tools) Or, since it shouldn't matter which python version is used for the tools they might be left out entirely from the package(s) for one of the two python versions.

de-vries commented on 2015-12-30 12:21 (UTC)

great, thanks :)

bchretien commented on 2015-12-30 00:03 (UTC)

@devries: updated, thanks!

de-vries commented on 2015-12-29 23:26 (UTC)

This currently fails to build in a clean chroot because of a missing makedep on python2-setuptools.

kartikmohta commented on 2015-02-18 19:08 (UTC)

catkin-pkg-0.2.7 is out