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
catkin tools plugin: add catkin tools support. #1593
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this @cratliff !
I just had a quick look and left a couple of nit comments, because I'll leave the full review to Kyle.
I think that we can refactor a base catkin plugin to make the inheritance clearer. One base, and then two implementations, one with catkin_make_isolated
and the other with catkin
. But your code looks very nice, we can do the refactor afterwards.
However, I'm not entirely convinced that this should be a separate plugin, instead of a single catkin plugin with an attribute like build-tool
. But I will just run away and leave that discussion to the two of you :)
snapcraft/plugins/catkin_tools.py
Outdated
@@ -0,0 +1,124 @@ | |||
# -*- Mode:Python; indent-tabs-mode:nil; tab-width:4 -*- | |||
# | |||
# Copyright (C) 2015-2016 Canonical Ltd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please update the copyright year here.
snapcraft/plugins/catkin_tools.py
Outdated
super().__init__(name, options, project) | ||
self.build_packages.extend(['python-catkin-tools']) | ||
|
||
def _prepare_build(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that this method is too long. Maybe it can be split into _clean_catkin
, _add_catkin_profile
and _install_catkin_packages
5821d1d
to
c466ae1
Compare
I edited the copyright and broke up the _prepare_build function to be to be a shorter. That refactor makes sense. I would be fine to do it now or later. @kyrofa and I talked about that at the rally. He had some thoughts about why this should be another plugin. One I know of is that catkin tools has a number of options that may be added later at the plugin is expanded that wouldn't be compatible with catkin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking pretty good. I'm not a catkin tools pro, so I have a few questions in here. Also, have you tried it with content sharing at all? Finally, we will definitely need a snapd integration test for this.
def _add_catkin_profile(self): | ||
# Overwrite the default catkin profile to ensure builds | ||
# aren't affected by profile changes. | ||
catkincmd = ['catkin', 'profile', 'add', '-f', 'default'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any downside to potentially overwriting this profile? Is it possible for the developer to create one with settings that are necessary for the build to succeed, and our overwriting it here causes it to fail? Likewise, I'm sure it's possible for their changes to break the build in the snap... perhaps that's more likely. Just want to get your thoughts on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a user I would probably prefer to be able to use in my own profile. It would mean the catkin tools plugin would be less maintenance as well, since almost anything you would want to add can be done directly through a profile. My thought was that a user's settings could break the build in the snap if they were utilizing some features, use source not in the parts directory, or not install properly. Would a field in the schema be appropriate to allow the user to use their profile understanding it could break things? Even if we allow the user's profile we would still want to change the source, build, and install space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your logic seems sound, here. Indeed, the schema seems a good place for this, but I think what we have here is a good and safe first step. Anything more could come as a follow-up.
@@ -401,7 +401,7 @@ def pull(self): | |||
|
|||
# Pull our own compilers so we use ones that match up with the version | |||
# of ROS we're using. | |||
compilers = _Compilers( | |||
compilers = Compilers( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's on my TODO to split this out into a common area, FYI.
catkincmd = ['catkin', 'config'] | ||
|
||
# Use the newly created default profile. | ||
catkincmd.extend(['--profile', 'default']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not set this profile to be active in _add_catkin_profile()
? It would save your needing to explicitly use it in every subsequent command, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because there was only one subsequent command, I'm good to change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need, just a thought.
catkincmd = ['catkin', 'build'] | ||
|
||
# Prevent notification that the build is complete. | ||
catkincmd.append('--no-notify') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this explode on headless systems? Might be kinda useful, really.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I'm aware of. My thought was that it could be confusing to receive a notification that your build is complete when you still need to go through the stage, prime, and snap steps of the build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's a good point.
self._compilers_path, self.PLUGIN_STAGE_SOURCES, self.project) | ||
|
||
# This command must run in bash due to a bug in Catkin that causes it | ||
# to explode if there are spaces in the cmake args (which there are). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this bug still bites catkin tools? What about this bug from of old?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping here.
'make nil python qmake scons \n' | ||
'autotools cmake go gulp kbuild ' | ||
'maven nodejs python2 ruby tar-content\n' | ||
'catkin copy godeps jdk kernel meson ' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, this is always so much fun to edit, right?
I don't have super strong opinions here, but let me lay out all my thoughts.
Long-term, if development continues on Catkin Tools and we don't see breakage between Catkin and Catkin Tools, I envision eventually replacing the Catkin plugin with this. We just need to ensure this plugin continues to be a superset of capabilities from the Catkin plugin, and they don't diverge. |
class CatkinToolsPlugin(snapcraft.plugins.catkin.CatkinPlugin): | ||
def __init__(self, name, options, project): | ||
super().__init__(name, options, project) | ||
self.build_packages.extend(['python-catkin-tools']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a note that this is a beta plugin? See the ruby plugin for reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping here.
No, by content sharing do you mean an overlay or underlay of the workspaces?
My initial transition to catkin tools required cleaning the build from catkin_make then using catkin tools. Transitioning should be simple enough. |
Right, take a look at |
I'm mostly +1 on this. I'm curious about the bash bug and I'd like it to be marked a beta plugin, but other than that you just have a conflict to fix. |
I tested the bash bug and am seeing it. I also tested content sharing, it did not work, but didn't get a chance to look into why. Since we had been talking about them I also tested the profile overwriting and cleaning a more. They might not be necessary and just me being overcautious. I'll make sure to add the beta plugin. |
So it's not actually fixed in catkin tools? Bah.
That's okay, we can figure it out after this lands. |
Adding suppot for catkin tools. Initially the only difference is the build is being performed by catkin tools instead of catkin_make, while all other function inherits from catkin_make. LP: #1693380
c466ae1
to
9b0eee0
Compare
Added the beta warning and fixed the conflict. |
snapcraft/plugins/catkin_tools.py
Outdated
self.build_packages.extend(['python-catkin-tools']) | ||
|
||
# Beta Warning | ||
# Remove this comment and warning once ruby plugin is stable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check the comment here-- still says "ruby" 😛 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a typo in the beta warning comment, but overall +1 from me.
Sorry for the delay @cratliff, our testing infra fell over and we're trying to get a release out the door. As soon as that happens stuff can start landing again. |
Adding suppot for catkin tools. Initially the only difference is the build is being performed by catkin tools instead of catkin_make, while all other function inherits from catkin_make. LP: #1693380
Adding suppot for catkin tools. Initially the only difference is the build is being performed by catkin tools instead of catkin_make, while all other function inherits from catkin_make. LP: #1693380
Adding suppot for catkin tools. Initially the only difference is
the build is being performed by catkin tools instead of catkin_make,
while all other function inherits from catkin_make.
LP: #1693380
./runtests.sh static
?./runtests.sh unit
?