add test to check if ros node is loadable, #463
Conversation
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
3 times, most recently
from
50ae99c
to
16b1f58
Compare
k-okada
changed the title
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
2 times, most recently
from
cb16ce7
to
6a6ea8a
Compare
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
9 times, most recently
from
92457fa
to
07ba7b4
Compare
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
from
e6143b4
to
c40f118
Compare
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
from
0933bf3
to
c69ce7f
Compare
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
2 times, most recently
from
3257b81
to
c98a8d9
Compare
If we use python2 PYTHON_INTERPRETER on 20.04, python2 fails to load rospy in /opt/ros/noetic, because rospy moduels are alraedy updated. If we use python3 PYTHON_INTERPRETER on 18.04, python3 can load rospy in /opt/ros/melodic by chance. c.f. jsk-ros-pkg#367
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
from
c98a8d9
to
0a9c6a7
Compare
…tory from BIN to SHARE, because we want to have same directory structure between devel and install
helper.py depends on dialogflow_task_executive. However, when we add this to the <depend> of package.xml, it appempts to build venv using 'dialogflow_task_executive/requirements.txt'. This requires having the same PYTHON_INTERPRETER for both dialogflow and chat ros package. The issue is that dialogflow_task_executive heavily relies on system Python modules, including ROS, making it difficult to use dialogflow with Python3 on Melodic
…epends on generate_messages
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
2 times, most recently
from
bcc2f0e
to
ed83715
Compare
…aarch64), other archtecture skips rospy_node.test
k-okada
force-pushed
the
fix_ros_google_cloud_language_on_python3
branch
from
ed83715
to
019466f
Compare
There was a problem hiding this comment.
@mqcmd196 @sktometometo please review this PR, I want to merge this and release new version to remove jsk_3rdparty from blacklist, see #468
google_chat_ros/CMakeLists.txt
Outdated
|
|
||
| # python | ||
| file(GLOB PYTHON_SCRIPTS scripts/*.py) | ||
| catkin_install_python( | ||
| PROGRAMS ${PYTHON_SCRIPTS} | ||
| DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} | ||
| ) | ||
| DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}/scripts/) |
There was a problem hiding this comment.
This PR changes the installed directory from BIN to SHARE
@mqcmd196
There was a problem hiding this comment.
@k-okada
I can understand that *.l libraries prefer to be on the same path for both devel and install. However, are Python files should be the same? They are resolved by rosrun if executable, and if the library, catkin_python_setup, setup.py do. I like to follow the common rule. Or for testing???
There was a problem hiding this comment.
That's an excellent question. I personaly do not like to install BIN directory, because devel and install should have same structure. Moreover, we've installed scripts and/or nodes under share directory using install CMake command, and it is unclear to me why we should relocate just to support Python3...
However, as an installing under BIN appears to be default behavior and I have changed my mind to fix all CMakeLists.txt, see 15c3e40
http://docs.ros.org/en/jade/api/catkin/html/howto/format2/installing_python.html
There was a problem hiding this comment.
devel and install should have same structure.
Yes, I have the same opinion. devel seems to have made the development for ros users easier, but they had to care about the file structures in both devel and install especially when releasing the package. In my understanding, ament and colcon stopped using devel because of it, right...?
https://design.ros2.org/articles/ament.html#:~:text=package%20on%20Windows.-,Devel%20space,-catkin%20has%20the
Anyway, thank you for your update
|
I do not know much about ROS package releasing. But ubuntu-sounds entry for ros_speech_recognition is not merged ros/rosdistro#36857 So ubuntu-sounds entry will not be resolved. |
|
yes, can you consider using freedesktop-sound-themes ?
--
◉ Kei Okada
2023年5月30日(火) 23:49 Koki Shinjo ***@***.***>:
… I do not know much about ROS package releasing. But ubuntu-sounds entry
for ros_speech_recognition is not merged ros/rosdistro#36857
<ros/rosdistro#36857> So ubuntu-sounds entry will
not be resolved.
(We have to use sounds in freedesktop-sound-themes).
Does this affect releasing process?
—
Reply to this email directly, view it on GitHub
<#463 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADYNXBVB67YRPIXHHTC7JTXIYCH7ANCNFSM6AAAAAAX5VOJRA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
If we use python2 PYTHON_INTERPRETER on 20.04, python2 fails to load rospy in /opt/ros/noetic, because rospy moduels are alraedy updated.
If we use python3 PYTHON_INTERPRETER on 18.04, python3 can load rospy in /opt/ros/melodic by chance.
c.f. #367