-
Notifications
You must be signed in to change notification settings - Fork 49
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
Provide a 'clean' verb #37
Comments
Be careful about overloading terms unintentionally. Clean usually only effects intermediate and output files not the installation path. https://stackoverflow.com/questions/1439950/whats-the-opposite-of-make-install-i-e-how-do-you-uninstall-a-library-in-li That's more like |
That is a good point. |
I think we all agree that the functionality described in this ticket is useful and should be added. The point @tfoote is trying to make is that |
How about |
That is already possible with |
@dirk-thomas in case of other sub-system than cmake ? (eg. Gradle...) And in case of gradle (seem to be same for cmake), target clean only (just a point of view of novice user.) |
I am not familiar with Gradle and don't know what it exactly does when running the For the For the case of invoking the existing |
The mixin concept is now available through colcon-mixin. |
I hear @tfoote's point that |
I agree with @scpeters, I'd prefer clean to work like it did in catkin tools. An important point of running clean is that it clears caches. As far as I know, install space will also have the problem that old files won't be removed. Let's say I used to have a node |
Also agree with @scpeters. An analogous command to |
Over on #213 (comment) , I have described a use case for this kind of verb. I'd like to request for the ability to selectively control the clearing of the build vs install sub folders on a per package level for optimizing build caching for incremental builds. Comment on there if you have further suggestions. I'm working on the assumption that the workspace was built using isolated install, and the source may have been changed between builds, so using a classic uninstall function from the build system may not completely clear the install folder. Having a verb to selectively delete these folder would spare the user from having to infer the base path for all build and install directories and enumerate purging of packages. BTW, what would this verb mean for logs? If a package was specified, would the verb clear the package sub directory in all time-stamped directories in the log folder? What should this do if a non isolated install is used, but a package name is given? Just error out? |
Without an explicit option for cleaning logs I don't think this verb should touch the log directory. Though an explicit option like "clean-logs --all / --older-than-a-week" could certainly help deleting obsolete log directory. But this functionality shouldn't be intersecting with the package selection arguments. I don't see a reason to only the logs of a specific package.
This is where you want / need the uninstall rules in order to be able to achieve the requested behavior. |
That's what I was feeling, as logs have lifetimes beyond that artifacts in build/install directories. |
Note that
Not to say that these aren't both pretty convenient, but for implementation and user sanity, I would support them having different names. |
Perhaps separate verbs?
|
Is anyone interested in reviving this work? After doing some ROS 2 development, I'd really appreciate this functionality. |
Hey folks! I made a quick implementation by coding this into two subverbs, allowing users to clean base folders within a workspace or on a per package bases. You can check it out and try it yourself here:
Perhaps we could upstream this into the colcon org, and bundle it up with colcon-common after some iterations and PRs? |
For potential uses of |
This reminds me of Bill Gates admitting Ctrl + Alt + Delete was a mistake. Let's admit it: |
Has anyone had the chance to try out the Perhaps we could migrate the extension repo to this colcon org and release it upstream. I think the scantree dependency for fast file path globbing may be the only issue, but perhaps that could be swapped an alternate regex approach. |
I miss |
@cottsay what is the procedure for adding https://github.com/ruffsl/colcon-clean to the |
It looks like @ruffsl's implementation with specific subcommands resolves my worries about clarity of the command. |
I started going down the path of adding |
@cottsay Friendly ping! |
@cottsay - I have opened two new tickets requesting the transfer and release of the new relevant extensions: |
Hey folks, colcon-clean has been released, so I think we can finally close this ticket! #521 (comment)
|
E: Unable to locate package python3-colcon-clean |
Due to missing python dependencies available with and after jammy, packing this extension couldn't be backported to Ubuntu focal. You could try still try using pip though. |
to delete
build
install
andlog
folder.Once the notion of profile is there it could delete the folders corresponding to that profile rather than the default folders
The text was updated successfully, but these errors were encountered: