strands-project / fremen

Other
10 stars 32 forks source link

Could frenap be moved out of this repo? #47

Open cdondrup opened 7 years ago

cdondrup commented 7 years ago

I would like to use fremen for our project (maybe) and noticed that when trying to build it, it depends on strands_navigation_msgs. Which means that if I want to build things from source, I have to check out the whole navigation stuff as well including all its dependencies which I don't need.

Of course, once there are packages for Kinetic one could install those and be done with it, but I am not sure I can convince everybody to set-up the strands repositories on their machines. Hence, it would be easiest if this otherwise very self-contained repo would not depend on strands_navigation_msgs. As far as I can tell, only frenap depends on those which also creates circular dependencies between the repos as discussed in #13.

If it is not too much of a problem, I would suggest moving frenap to strands_navigation instead. This would solve the circular dependencies issue as far as I can see and would also mean that this repo only relies on officially released packages. Also, I am not sure if frenap is supposed to be used without strands_navigation in the first place.

All this is, of course, just a suggestion so please ignore me if it is too much work or you disagree. The workaround is just deleting frenap from my local fork so not much of a problem. Just thought I'd share my two cents.

gestom commented 7 years ago

Hi Christian, yeap, it does make sense to move frenap to strands_navigation. Feel free to proceed :)

Jailander commented 7 years ago

Hi, I am not sure about this, I actually think it makes no sense to keep it in the main branches how about moving it to a deprecated branch? is not in use anymore.

cdondrup commented 7 years ago

If it is not in use in could indeed be moved to a deprecated or legacy branch. Just a matter of in this repo or in strands_navigation.

marc-hanheide commented 7 years ago

I agree it shouldn't be in here. If it end in a "dead" branch, it will effectively be dead. Which is fine, if it's not being used in the future. But if it will be then we should move it somewhere else. But, for now, I'm happy for you to create a "strands-legacy" branch and proceed.