Is there a reason uninstall doesn't take depth?

[a-olguin]

I use gitman in a project of projects where several repos also use gitman to handle their dependencies, and this all works well.

However, for reasons at least one of those dependency projects uses location=. and routes dependency checkouts to different subdirectories through the name field of the gitman yaml.

This was fine until I went to uninstall my top level repo during cleanup and discovered that it infinitely recursed on the problematic dependency. I tried adding the depth flag to stop the recursion and see that it is unrecognized for uninstall. I see that in the implementation we use get_dependencies which can take a depth, and so I think see a clear way to wire depth through the arg parser down to the delete command, but want to make sure there wasn't a subtlety in the project I didn't appreciate before I make a PR.

[jacebrowning]

I believe the assumption was that dependencies would be nested in subdirectories so deleting the top-level directory would be sufficient to invert the install action.

[a-olguin]

dependencies would be nested in subdirectories so deleting the top-level directory would be sufficient

This is sort of true, the delete command used by uninstall checks if this is safe (location==.) and either deletes the subdir or does a clean that appears to walk the checkout dots, so it looks like this case is supported. Where this bites you is it a dependency itself has location==.- then the unbound get_dependency walk finds a cycle repeatedly stepping out and in trying to get_dependencies for that dependency. Haven't traced it too closely yet but I'm pretty sure this is unintended.

I could probably add either a ledger of loaded configs&their paths to this process or just route the depth field through if this is worth fixing to anyone else.

[jacebrowning]

I think I'd be open to a small change to prevent the infinite loop (e.g. checking previously visited paths) rather than adding --depth to uninstall, since --depth=1 won't do what one expects for typically-nested dependencies.