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

« First ‹ Previous 1 2 3 Next › Last »

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

« First ‹ Previous 1 2 3 Next › Last »