-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to call pyros_setup ? #46
Comments
Idea:
If the variable is set => we raise exception directly Maybe that check should be in pyros_setup itself... |
A better way to use pyros_setup could be : try:
import something
except ImportError:
import pyros_setup
if pyros_setup.activation_required:
pyros_setup.configurable_import().configure().activate()
import something
else:
raise |
Another possibility would be to leverage the "next" pyros structure (with plugins - probably using pkg_resources). This way we could so something along the lines of : try:
import pyros_rosplugin # we use only one specific package that is ONLY in ROS
except ImportError:
import pyros_setup
if not pyros_setup.activated: # that would be the list of distro + workspaces from configuration
pyros_setup.configurable_import().configure().activate()
import pyros_rosplugin
else:
raise
import <more random ros packages> as a first step we could implement that "activated" member (or similar, maybe it s just in need of documenting...) and rely on rospy as a lowlevel package existing only in ros distro. |
Note that We could have ROS activated by a source, but catkin_pip wouldn't put the editable packages at the beginning of the pythonpath. However this is done by pyros-setup and required by ROS to work as expected with existing pythonpath mechanism and editable packages. (Does this mean we have a design flaw somewhere since we cannot use catkin_pip OR pyros-setup, but in some cases have to use both ? ) That being said, activating pyros-setup multiple times might be permitted or not, it depends on pyros-setup itself. So in the end it might be better if it wasn't checked at all here (but it might be inside pyros-setup However we still need a way to determine if we should raise the previous |
Regarding previous comment, I think catkin_pip should not rely on pyros_setup, so that design problem should be fixed... On another part, we should probably check if ROS itself is activated (to prevent import pyros_setup if it is the case -> we dont need it). We should probably use one of the ROS environment variables... |
So it seems we are targeting something like : if not 'ROS_DISTRO' in os.environ:
import pyros_setup
pyros_setup.configure().activate()
import rospy This should attempt to import pyros_setup only when ROS is not loaded. |
We need to find a better way to use pyros_setup.
Currently the user is supposed to do :
The main drawback with this is that if an import trigger an error, which is not related with setting up ROS, it will be hidden by a further error, potentially related with pyros_setup...
The text was updated successfully, but these errors were encountered: