Package Details: python-catkin_pkg 1.0.0-1

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
Last Packager: kartikmohta
Votes: 10
Popularity: 0.000000
First Submitted: 2017-06-01 00:23 (UTC)
Last Updated: 2023-09-27 06:08 (UTC)

Latest Comments

1 2 3 Next › Last »

MarsSeed commented on 2023-07-19 10:34 (UTC)

No problem, thanks for the update!

kartikmohta commented on 2023-07-19 05:22 (UTC)

@MarsSeed @dreieck Sorry for the late response. I updated the package, thanks for your help!

dreieck commented on 2023-05-12 12:28 (UTC)

python-argparse must be removed from the depends array, see ↗ here.

Thanks for maintaining!

MarsSeed commented on 2022-07-09 23:48 (UTC)

Hi,

I've noticed that according to 'install_requires' in setup.py, this does not depend on python-argparse anymore.

However, python-setuptools should be in depends=(), not (just) in makedepends=().

Thank you in advance if you could look into this matter.

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.

1 2 3 Next › Last »