running macports along with homebrew

[Ryan Schmidt]

On Aug 31, 2017, at 10:53, Ken Cunningham wrote:

> I think homebrew gets attention for two reasons.
> 
> 
> 1. a one-line copy & paste install command that is pasted into the terminal  (macports could / should do that too, BTW).

While I agree our web site, including installation instructions, needs to be streamlined, it's not clear to me that offering a one-line install command is a good idea, to the extent that I'm not sure it's a good idea to blindly download and run a script you don't know. MacPorts has an installer package that's signed, which conveys a level of trust and security, and Mac users should not be unfamiliar with the notion of downloading and running an installer package. I dare say more Mac users would be familiar with that than pasting a command into the terminal.

But it should be possible to write a shell script that installs MacPorts by downloading and installing the right pkg, if someone is keen to work on that.


> 2. the fact that it symlinks it's stuff into /usr/local, making it easier to use it's installed products for building other software for amateurs (macports could do that too).

We won't put things in /usr/local. It's been discussed to death why that would be a very bad idea. See e.g.

https://trac.macports.org/wiki/FAQ#defaultprefix

and

https://trac.macports.org/wiki/FAQ#usrlocal


> 3. My impression is that it's not so difficult to get things accepted. If a submission builds on Travis on 10.10 to 10.12, it's usually in homebrew within a day or so, it seems.

I'd echo what's been said elsewhere: if a MacPorts ticket or PR isn't getting attention after a few days, you can remind the macports-dev mailing list about it and hopefully someone will get to it. If we don't have enough developers getting to such things, that may indicate that we need to approve additional developers for commit access. The process for requesting commit access is documented in the guide. Sometimes we managers need reminders about answering those requests too, but we really do want to grant commit access to good developers who want to help, and that especially means developers who won't confine themselves to just updating the few ports they personally care about, but rather those who will seek out and handle open tickets and PRs for other ports.