On Feb 14, 2018, at 2:46 PM, Ken Cunningham <ken.cunningham.web...@gmail.com>
> On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote:
>> We will definitely never offer a user-facing feature for building the HEAD
>> version of a port's code.
> I completely recognize why you stick with this, I totally get it, but this
> caution is costing MacPorts both users and mindshare to do so... some people
> want this, and so will go elsewhere to get it.
> In a recent poll
> <https://www.slant.co/versus/1588/1674/~macports_vs_homebrew>, homebrew was
> recommended 375 to 25 over MacPorts.
> Most developers who offer their software for download and building manually
> recommend homebrew for supporting software. Almost nobody recommends MacPorts.
sure, it's not clear that that's because MacPorts doesn't provide un-repeatable
> Reasons for this are likely to be:
> 1. a one-line copy-paste install script that can be embedded into any webpage.
> 2. symlinks into /usr/local therefore:
> a) no adjustments needed to path
> b) no need for sudo
> c) third-party apps, libraries, and xcode projects can be downloaded and
> built or run, and the system looks there by default, so need no modification
> to build or run.
> 3. you can easily build the +HEAD version of a git project to try out newest
> changes as a beta tester
> IMHO, the two biggest reasons homebrew is heavily recommended are #1 and #2c.
> I think it's just good that we all know this.
> Is there anything that would stop someone from installing macports into
> /usr/local ,
yes, the configure script purposely errors out if you try to do this (I ran
MacPorts this way for a /long/ time - there's no real benefit from doing so).
> should they desire to do so? That would fix up all the issues with sudo,
> path, and 2c.
MacPorts already works with non-sudo if you want (we could probably make it
Daniel J. Luke