Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pregenerated html docs #32

Closed
chutz opened this issue Oct 23, 2012 · 6 comments
Closed

pregenerated html docs #32

chutz opened this issue Oct 23, 2012 · 6 comments

Comments

@chutz
Copy link

chutz commented Oct 23, 2012

Please provide pregenerated static html docs in your release tarballs, or provide a way to generate them at install time.

Not every machine will have a internet access, and installing an extra daemon for docs is often not an option.

@stedolan
Copy link
Contributor

Good idea, will do for next release.

@stedolan
Copy link
Contributor

Release 1.3 has pregenerated docs.

@ghost
Copy link

ghost commented May 22, 2013

I see the tarball (http://stedolan.github.io/jq/download/source/jq-1.3.tar.gz) has jq.1 pregenerated man page - it would be great to have pregenerated html docs too.

Also, would you consider including both these in the commits? I know it's inefficient, repeating the yml expanded to html, but it would be convenient to not have to install ruby etc to see html docs for the development version.

@stedolan
Copy link
Contributor

Yeah, the tarballs should probably ship with docs/output prebuilt.

Including the pregenerated stuff in the commits is unlikely to happen. Efficiency isn't the concern. I do actually read the commit logs, especially when debugging, and I don't want every change to be eclipsed with a few hundred lines of manpage and HTML. Also, when merging branches and pull requests, there would almost invariably be conflicts between two branches' versions of generated docs.

Do try RVM if you haven't already (see docs/README.md). One command will get a Ruby install up and running.

@ghost
Copy link

ghost commented May 22, 2013

Diffs are a really good point. (The merging point is even better.) it might be possible to have a separate branch for them (automatically handled), but a hassle.

I've tried RVM. It's a nightmare, the complex fragmented docs, the different versions of itself. Ruby also is a nightmare, with breaking changes in point releases. It used to be an easy language to get started with, but now is more serving established users/experts/commercial users. Java had this baked in from the start, whereas ruby is a fun, radical language trying to become a suit. </rant>

I'm also running into disk-space limits on my tiny machine, so that's probably the real reason :-). I might try your RVM oneliner https://github.com/stedolan/jq/blob/master/docs/README.md

@stedolan
Copy link
Contributor

I'm also running into disk-space limits on my tiny machine, so that's probably the real reason

RVM does like to download all of the internet twice. I wouldn't know about its terrible docs, I don't think I've ever read them beyond "copy-paste this line into your shell and suddenly a Ruby appears".

The breaking changes in point releases of Ruby are indeed horrible. The one-liner in README.md downloads the version of Ruby I'm using; I haven't tested others.

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

No branches or pull requests

2 participants