On Feb 14, 2018, at 13:46, Ken Cunningham 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.
If you refer specifically to the fact that we don't support building a port from HEAD, I've literally never heard anyone ask for that feature on the MacPorts lists, until this thread. > 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. I'm sorry to hear that. > 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 The MacPorts installer adds /opt/local to the PATH. So MacPorts requires no manual adjustments of the PATH either. > b) no need for sudo That does not follow. We use sudo because it increases security to do so. > 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. Nothing prevents portfiles from being written that install things people want installed. We certainly have ports that install apps and libraries. I don't understand why anyone would want a port that installs an Xcode project. I don't know what you mean by "system looks there by default". > 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. I have heard some complaints about our installation process before. Running a single installer package should not be too onerous; lots of software is successfully distributed in that way. It is perhaps inconvenient that we require the user to install Xcode and the command line tools first. Some work has been done to streamline that to the point that only Xcode and not the command line tools will be required for MacPorts 2.5 and up. I'm not certain if we could streamline it further. Perhaps the installer could contain more prominent links to download Xcode from the App Store or something. > Question: > > Is there anything that would stop someone from installing macports into > /usr/local , should they desire to do so? That would fix up all the issues > with sudo, path, and 2c. Yes, the MacPorts configure script deliberately prevents users from selecting /usr/local as their prefix, because doing so would cause problems and we do not want to experience the support burden of users doing so. https://trac.macports.org/wiki/FAQ#defaultprefix
