technicalpickles/homesick

Creating consistent commands

christianbundy opened this issue · 11 comments

It's trivial, but personally, I've found myself typing homesick link abc/xyz – and after thinking about it, it seems like we have an issue with consistency between commands.

I think that we should decided on whether the command should be symlink or link (I prefer the latter for brevity), and format both commands to adhere to that. Either:

homesick link abc/xyz
homesick unlink abc/xyz

or

homesick symlink abc/xyz
homesick unsymlink abc/xyz

But mixing and matching commands is confusing, and I don't think that it's the best way to go.

+1

I would prefer link/unlink too.

On Wed, Nov 27, 2013 at 8:08 PM, Christian Bundy
notifications@github.comwrote:

It's trivial, but personally, I've found myself typing homesick link
abc/xyz – and after thinking about it, it seems like we have an issue
with consistency between commands.

I think that we should decided on whether the command should be symlinkor
link (I prefer the latter for posterity), and format both commands to
adhere to that. Either:

homesick link abc/xyz
homesick unlink abc/xyz

or

homesick symlink abc/xyz
homesick unsymlink abc/xyz

But mixing and matching commands is confusing, and I don't think that it's
the best way to go.


Reply to this email directly or view it on GitHubhttps://github.com//issues/62
.

I agree. I think this could be a good project to figure how we can refactor
the code base to be easier to manage as well. I think with the single file
approach it's makes it easier to add duplicate code and makes it harder to
manage the test suite.
On Nov 27, 2013 11:08 AM, "Christian Bundy" notifications@github.com
wrote:

It's trivial, but personally, I've found myself typing homesick link
abc/xyz – and after thinking about it, it seems like we have an issue
with consistency between commands.

I think that we should decided on whether the command should be symlinkor
link (I prefer the latter for posterity), and format both commands to
adhere to that. Either:

homesick link abc/xyz
homesick unlink abc/xyz

or

homesick symlink abc/xyz
homesick unsymlink abc/xyz

But mixing and matching commands is confusing, and I don't think that it's
the best way to go.


Reply to this email directly or view it on GitHubhttps://github.com//issues/62
.

I completely agree. What else would we be looking to do if we were to refactor?

What I am hoping to see out of the refactor is the ability to put each group of command in its own class/file e.g. symlink/unsymlink and the ability to have a test file for just these commands. I think this is going to make it easier to add/edit commands and make it easier for us to add some test coverage so its a bit less scary to change things.

I was originally planning on working on some install/uninstall commands that would basically wrap the clone/symlink process

If we are going to brevity, could also think about ln to mirror the symlink command. Not sure what the inverse would look like.

Maybe rm? Removing a symlink is the same process as removing a file, so it would make sense to ln and rm. I think that ln is great either way though.

Yeah, I think I can get behind ln and rm.

@trobrock Nice idea on the refactoring. I already started some more trivial refactoring on my fork's refactor branch (mostly just rubocop fixes for now). I was planning on doing more serious refactoring, and I can help you out if you'd like. We could also create an issue for refactoring if you think that would help.

@thenickperson a new issue is probably the way to go.

@trobrock I added some of your suggestions to #76. I did not add some things like renaming commands to ln and rm, or adding install/uninstall commands, because I felt that they were less related to refactoring. Let me know if you think I should change that.

I'm going to close this issue now that #87 has been merged. Feel free to reopen if anyone thinks there's a need.