[WIP] Add manual #15
[WIP] Add manual #15
Conversation
|
The modified help sentences in 304e112 were a nice attempt, but should not be merged |
|
|
||
| - *1. where do these packages come from??* | ||
| - Would be the ros-distro story, but needs a good place in the manual. | ||
| - perhaps an example and a eference to the REP. |
There was a problem hiding this comment.
You create a rosdistro according to REP 143. Example for the tue-robotics software: https://github.com/rayman/rosdistro
I made one modification, the packages field example is added for the source packages field. When this field is present, installation with ros-get is possible.
|
|
||
| - *2. which branch?* | ||
| - ``ros-get update`` does what wrt branches? | ||
| - should it do other things with branches too? (make them, remove them, switch between them, push them, fetch/pull them, etc) |
There was a problem hiding this comment.
Good question, we should discuss this. My personal preference is the following
- install
- if the repo doesn't exist: checkout the repo @ target branch
- else: just
git pullthe current branch and warn that you're on the wrong branch
- update
- if the repo doesn't exist: checkout the repo @ target branch
- else: just
git pullthe current branch and warn that you're on the wrong branch
Does that make sense?
There was a problem hiding this comment.
I think it is up to the user to switch branches. And to make sure they're working on the branch they want to work on.
Warnings on an update would be a bit overdone no? If they want to know they can run a ros-get status or something.
| - *3. are all branches updated?* Assuming you can have some repos using a different branch, are these updated too, or is that configurable, or? | ||
|
|
||
| - *4. is this true?* | ||
| - ``ros-get list`` seems to list the top-level packages? |
There was a problem hiding this comment.
That is true, maybe that functionality should be moved to an --installed argument. By default list ALL packages?
| - ``ros-get list`` seems to list the top-level packages? | ||
| - *5. get other information?? how??* | ||
| - can it provide other lists (manually installed as required versus installed as dependency, for example) | ||
| - can you get packages that nobody needs any more? |
There was a problem hiding this comment.
The python package catkin_pkg can be used to parse the package.xml files we have on disk and resolve the dependencies. This is indeed work that can be done.
| - ``ros-get remove`` considerations: | ||
| - *6. really? what if it is needed by some other package??* Can you remove a package that is needed as dependency? | ||
| - *7. is a package removed automatically by itself when it is not required any more??* is that desired? | ||
| - *8. if so (if automatically removed), can you avoid that?* |
There was a problem hiding this comment.
- Currently its broken. It should remove top-level packages.
- We should have an
autoremovecommand which does that. TODO
| - ``tue-get --release`` build Debian package`` (looks catkin-ish) | ||
|
|
||
| - ``tue-make`` / ``tue-make-dev`` / ``tue-make-dev-isolated`` / ``tue-make-system`` | ||
| - probably provided by catkin already? |
There was a problem hiding this comment.
We should make an alias like:
alias tue-make='catkin build --workspace "$(ros-get ws-locate)"'| - ``tue-make`` / ``tue-make-dev`` / ``tue-make-dev-isolated`` / ``tue-make-system`` | ||
| - probably provided by catkin already? | ||
|
|
||
| - ``tue-revert`` and ``tue-revert-undo``. |
There was a problem hiding this comment.
I made these. They revert all packages to a certain point in time. Useful for "Help we need to revert back to yesterday immediately!!"-situations.
Basically high level: ros-get upgrade gives the latest versions. But maybe you sometimes don't want the latest but a specific point in time.
But maybe this is also very tue specific.
| - ``tue-revert`` and ``tue-revert-undo``. | ||
|
|
||
| - ``tue-create ros-kpg PACKAGE_NAME [DEPENDENCY1 DEPENDENCY2 ..]`` code generator for ROS package boiler-plate | ||
| - ``tue-create cpp-class CLASS_NAME PROJECT SUPER_CLASS`` code generator for cpp class. |
There was a problem hiding this comment.
There is already catkin_create_pkg
|
|
||
| - ``tue-create ros-kpg PACKAGE_NAME [DEPENDENCY1 DEPENDENCY2 ..]`` code generator for ROS package boiler-plate | ||
| - ``tue-create cpp-class CLASS_NAME PROJECT SUPER_CLASS`` code generator for cpp class. | ||
| - ``tue-env cd`` woud at least be bash. Likely also exists as ``roscd``? |
There was a problem hiding this comment.
Yeah, roscd is fine, or make an alias. We used to have the trunk alias.
| - time-zone commands | ||
| - apt-get-proxy | ||
| - ``tue-save-map`` | ||
|
|
There was a problem hiding this comment.
These are robotcup specific aliases that should be in their own package.
| allowing you to use it with the other workspace commands. | ||
| The command is | ||
|
|
||
| ros-get ws-create [--name NAME] DIRNAME [EXTEND] |
There was a problem hiding this comment.
This changed on the latest commit :)
|
It would be really nice if we could have the ocumentation available on readthedocs.io #24 . Maybe we can auto generate parts from code? Let's look into this next tuesday. |
No description provided.