On Feb 14, 2018, at 2:46 PM, Ken Cunningham <[email protected]> wrote: > 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 HEAD builds. > 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. > > Question: > > 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 easier). -- Daniel J. Luke
