<html><body bgcolor="#FFFFFF"><div>Well said. I feel the same way, preferring web docs and the simplicity of homebrew.<br><br>-Shane<div><br></div></div><div><br>On Sep 18, 2010, at 6:34 PM, Jon Brisbin &lt;<a href="mailto:jon@jbrisbin.com">jon@jbrisbin.com</a>&gt; wrote:<br>
<br></div><div></div><blockquote type="cite"><div><br><div><div>On Sep 18, 2010, at 4:52 PM, Matthew Sackman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>_I_ am distinctly unhappy about the fact that if homebrew continues to<br>
become more popular, more and more RabbitMQ users are going to be<br>installing it without the documentation. We put time and effort into the</div></blockquote><blockquote type="cite"><div>man pages, and I will _always_ refer to locally installed documentation<br>
in preference to websites: you should always be able to trust that the<br>locally installed documentation matches the version of the software you<br>have installed. </div></blockquote><div><br></div>I guess we&#39;ll have to agree to disagree on how developers use documentation. I can&#39;t speak for others, but I don&#39;t use man pages unless I&#39;m forced to. When I&#39;m developing, I have about a dozen tabs open with the various documentation sources I need while I&#39;m developing. I use online documentation *exclusively*. I do have a few things with documentation installed locally. Spring framework and the Java SE API docs being the two I use most frequently. But I usually do that because they&#39;re so big.</div>
<div><br></div><div>For everything else, I always, always, always use the resources available online. I do that because I switch back and forth between the official docs and googling for examples. I mix other sources in with official documentation. I can&#39;t do that if I&#39;m locked into less on a terminal. </div>
<div><br></div><div>Sorry to burst your bubble, but I *really* hate man pages. I use them for finding out what options I need to pass to a program because it&#39;s been a while since I&#39;ve used it and I don&#39;t quite remember. For that, they&#39;re really handy. I don&#39;t use them for anything else.</div>
<div><br><blockquote type="cite"><div>Some software, in e.g. Ubuntu LTS releases, or Debian<br>Stable releases, can be 5 years old and no, I would not expect the<br>authors to clutter their websites with historical records of past<br>
documentation. </div></blockquote><div><br></div><div>Having old versions of things on their website is an expectation I have. Maybe it&#39;s unrealistic. I can see no downside to having old versions of documentation hanging around for users of older versions of the software. If you put the version of your documentation in a position:fixed nav box somewhere on the page, you&#39;ve addressed the problem of being half-way through a page of docs and forgetting what version you&#39;re looking at. </div>
<div><br></div><div>When you write the documentation, if you cover a new feature introduced in that version, you simply put a &quot;since: 2.1.0&quot; or something. If enough of these are sprinkled throughout, people get used to that easily and understand that this feature was introduced in version 2.1.0. The python docs are great examples of this.</div>
<br><blockquote type="cite"><div>I would however expect to be able to install the<br>documentation, if it isn&#39;t already, via the package manager, and know<br>that it matches the version of the software I have installed.<br>
</div></blockquote><div><br></div>I think that&#39;s reasonable, but I go back to agreeing to disagree on what format most developers prefer to use documentation in. Erlang folks I think are a little skewed because of the prominence of Emacs, info docs, and the really old school conventions that are perfectly functional but aren&#39;t taking advantage of new possibilities.</div>
<div><br><blockquote type="cite"><div>There are other optional dependencies of Erlang, for example X Windows.<br></div></blockquote><div><br></div>Uggh. X. Don&#39;t get me started on that! :)</div><div><br><blockquote type="cite">
<div>I can&#39;t see any<br>evidence of X Windows at all looking through the homebrew list at<br><a href="http://github.com/mxcl/homebrew/tree/master/Library/Formula/"><a href="http://github.com/mxcl/homebrew/tree/master/Library/Formula/">http://github.com/mxcl/homebrew/tree/master/Library/Formula/</a></a>. </div>
</blockquote><div><br></div><div>Thank heavens! :)</div><div><br></div><div>XQuartz is awesome and everything I need in an X distro.</div><br><blockquote type="cite"><div>Again, the<br>correct solution is demonstrated by Linux distributions which for<br>
example have both erlang and erlang-nox packages thus allowing you to<br>choose which is installed. Then RabbitMQ can depend on erlang |<br>erlang-nox. In fact, in modern linux distributions, Erlang has been<br>split up into many smaller packages so that packages really can express<br>
precisely which parts of Erlang they depend on, which bits are<br>optional, and which bits have no bearing at all on the package.<br></div></blockquote><div><br></div>I do like this because it really burns me that I have to install X on server machines that will never have an X session run on them because it&#39;s a dependency.</div>
<div><br><blockquote type="cite"><div>Over the last 20 years, Linux distributions have honed package managers.<br>It&#39;s no surprise that these days rpm and deb systems are comparable in<br>power in terms of package management and are extremely capable. _I_ am<br>
frequently amazed at how incapable package management is on other<br>platforms.<br></div></blockquote><div><br></div>I wish there were aptitude for Mac. If someone wants to really make Mac developers happy, they&#39;d port apt to OS X and have a little GUI to download binaries, like you suggest.</div>
<div><br></div><div>Until such time I&#39;ll use Homebrew because it takes up less space on my harddrive and has fewer &quot;parts&quot; to keep track of.</div><div><br><blockquote type="cite"><div>IMHO, most of the pain caused by macports is only addressed by<br>
homebrew&#39;s packages _seeming_ to do the absolute minimum required to<br>make something compile at the cost of excluding (almost?) all optional<br>features and components.<br></div></blockquote></div><div><br></div>I can&#39;t speak for anyone else, but having every possible option turned on by default is the reason I don&#39;t like macports. The fact that Homebrew does exactly what you&#39;ve pointed out is why I like it! :)<br>
<div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Palatino; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Times; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br class="Apple-interchange-newline">Thanks!</span></font></div><div><font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br>
</span></font></div><div><font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; ">J. Brisbin</span></font></div><div><font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; "><a href="http://jbrisbin.com/"><a href="http://jbrisbin.com/">http://jbrisbin.com/</a></a></span></font></div>
<div><font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br></span></font></div><div><font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br>
</span></font></div><font class="Apple-style-span" face="Palatino" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br></span></font></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</span>
</div>
<br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>rabbitmq-discuss mailing list</span><br><span><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a></span><br>
<span><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a></span><br></div></blockquote></body></html>