Skip to content
This repository was archived by the owner on Feb 19, 2019. It is now read-only.

WIP - help refactor #288

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

corkupine
Copy link

Made chocolatey help much slimmer, and basically pointed to chocolatey [command] help. Implemented chocolatey install help to see if this approach will be satisfactory.

Also...yeah...it's still messy w/ comments and junk. I'll clean that up.

Ref #281

 - Slim down `chocolatey help`
 - Implement `chocolatey install help`
@gep13
Copy link
Member

gep13 commented May 6, 2013

I really think that this is a good idea! The only concern that I would have would be keeping what is in the "help" in source, in sync with the "help" on the wiki. I mentioned this to @mwrock in a previous commit that I saw him doing where he had to manually update a synopsis on the wiki to match a change to the synopsis in the code. Is there any way to have "one source of truth", i.e. that we store the help documentation and synopsis information in one place, e.g. in the source code repo, and then flow this through into the wiki. That way you update once, and it is correct in both places?

Just a thought...

@ferventcoder
Copy link
Contributor

On the nu project, one of our committers was able to pull and display the text from the wiki pages for help commands. It was pretty neat, but it requires that you are online.

@gep13
Copy link
Member

gep13 commented May 6, 2013

Hmm, that isn't bad actually, and not unlike other systems, for instance, PowerShell itself with it's Update-Help option. Would it make sense to use the wiki as the "one source of truth" and then have Chocolatey download and cache the help files locally?

Thoughts?

@ferventcoder
Copy link
Contributor

That sounds pretty interesting. We'll start somewhere though with this and work towards something like that.

@rismoney
Copy link
Contributor

rismoney commented May 6, 2013

gep13 I like that idea A LOT

https://github.com/blog/699-making-github-more-open-git-backed-wikis

As an alternate idea-
I like the way the cli for git itself works. A really lean version of help is available locally. For the verbose help it sends you to the wiki. The only time I don't have internet access is in production, where I shouldn't be needing extended help or else boo to me.

@gep13
Copy link
Member

gep13 commented May 6, 2013

@rismoney The more I think about this, the more I like it. Will add it to my ever growing list of things to look into :-)

@corkupine
Copy link
Author

So what do you think I keep going in the same direction for now? It's close to the git model, will be an improvement, and you can consider caching wiki pages and rendering markdown in the console later ;)

@gep13
Copy link
Member

gep13 commented May 7, 2013

As an experiment, i think it would be good to know that we can load a file from file system and render as help text when requested. I don't see why we couldn't do this though.

But yes, i think for now, that is the plan.

Gary

Sent from my Windows Phone


From: corkupinemailto:[email protected]
Sent: ‎07/‎05/‎2013 02:07
To: chocolatey/chocolateymailto:[email protected]
Cc: Gary Ewan Parkmailto:[email protected]
Subject: Re: [chocolatey] WIP - help refactor (#288)

So what do you think I keep going in the same direction for now? It's close to the git model, will be an improvement, and you can consider caching wiki pages and rendering markdown in the console later ;)


Reply to this email directly or view it on GitHub:
#288 (comment)

@gep13
Copy link
Member

gep13 commented May 7, 2013

Or, as a half way house, how about the following...

Continue with what you are currently doing, but rather than put the help documentation directly in the PowerShell script, move it into a separate file, one file for each method. Then, when requested, read that line, and display to user.

With that in place, we can then look to update those files, based on what is in the wiki, using something like a Update-Help method.

Thoughts?

Sent from my Windows Phone


From: corkupinemailto:[email protected]
Sent: ‎07/‎05/‎2013 02:07
To: chocolatey/chocolateymailto:[email protected]
Cc: Gary Ewan Parkmailto:[email protected]
Subject: Re: [chocolatey] WIP - help refactor (#288)

So what do you think I keep going in the same direction for now? It's close to the git model, will be an improvement, and you can consider caching wiki pages and rendering markdown in the console later ;)


Reply to this email directly or view it on GitHub:
#288 (comment)

@ferventcoder
Copy link
Contributor

Wow, if @github let's me edit your comments, it should show that I edited for accountability. Seems like something that could seriously be abused. I could change your entire statement there @gep13. Thoughts @haacked??

@gep13
Copy link
Member

gep13 commented May 7, 2013

@ferventcoder I guess this relies on you being a stand up, all around good guy! Oh, wait... :-)

I think this should be for any edit on the comment, regardless of who made the edit.

@corkupine
Copy link
Author

@gep13 Separate files it is. My availability is pretty well saturated with work, so will get to it as I can.

@ferventcoder
Copy link
Contributor

I hear that. Separate files is awesome, but what is the standard naming convention for the files?

@gep13
Copy link
Member

gep13 commented May 7, 2013

What about something like:

Help-<Function Name>.txt

i.e.

Help-Chocolatey-Install.txt

@ferventcoder
Copy link
Contributor

There is a convention for powershell for help file naming. Perhaps we should look it up?

@gep13
Copy link
Member

gep13 commented May 7, 2013

Ah, I see what you are getting at. My bad!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants