port "cask" -- installing prebuilt binaries

[Craig Treleaven]

> On Aug 6, 2020, at 11:29 AM, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
> 
> All valid points. I thought we had more-or-less got past the “should we” and moved on to the “how should we”, 
> 
> I am not necessarily championing this, but people are submitting these, and there is demand.here are nearly 4000 cask installer formulae on brew now. If similar binary-only ports are going to be accepted, I was hoping for a mechanism to identify and control them somewhat, for the reasons you mention and more.
> 
>> 
>> So, pretend I don’t know how Homebrew’s cask system works.  (I don’t.)  
>> 
>> 1) As a user, what is the advantage of this kind of system versus other avenues for software (i.e. the Mac App Store or direct download of a dmg from the developer web site)?  
> 
> convenience, really. You can install something with a short command instead of wading through finding the right installer on a website. Updates are handled transparently. You can install 10 or 20 software packages onto a set of systems with one command. You can make a list of the 75 software packages you like to have and install them all with one command. You can tell your grandmother how to install zoom with four words to paste into a terminal instead of a complicated set of download and install instructions. 
> 
>> Doesn’t most such software include an auto-updater?  
> 
> Sometimes.
> 
>> If so, won’t that conflict with MacPorts update handling?  
> 
> Yes.
> 
>> A potential disadvantage would be the time lag from a new version being released until a new ‘cask’ is available, right?
> 
> Yes

If I understand correctly, this is a facility that would only benefit system administrators that have a fleet of Macs that are more-or-less configured the same.  It would help them to automate the process of installing and updating software whether the software is open-source or only available as a binary.  (But not software that is only on the Mac App Store.)  Is that right?

That is a worthy audience but why is this something that MacPorts should address?  I believe there are already 'multiple device management systems' out there that support macOS.  And if Homebrew already provides 4,000 packages, why do we want to do the same?  Is it not possible to combine Homebrew’s casks with open source software installed by MacPorts?

MacPorts is not in competition with Homebrew.  Really.  The projects have different objectives and goals and that is perfectly fine.  Both communities have sufficient support to continue for the foreseeable future.  We don’t have to “defeat them” to “win” or vice versa.  We seem to be aiming to replicate their cask system.  Should we not be aiming to provide a system that is demonstrably *better* than what is currently available?

All that said, one more question.  As I now understand it, the idea is to download a binary-only installer (from the publisher’s web site) and launch it.  Someone still has to answer any and all dialogs that such installers always present.  So, it fact, the administrator has to sit at the machine and click “OK” ad nauseam.  Previously, I thought we were going to create a new binary image that would avoid such tedium.  Do I have this right?  Or is there some scripting trickery wrapped around the installer?

Personally, I don’t see any compelling reason why the MacPorts project should want to go in this direction.  The first paragraph on our homepage says:

"The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac operating system <http://www.apple.com/macos/>. To that end we provide the command-line driven MacPorts software package under a 3-Clause BSD License <http://opensource.org/licenses/BSD-3-Clause>, and through it easy access to thousands of ports that greatly simplify <https://guide.macports.org/#introduction> the task of compiling and installing <https://guide.macports.org/#using> open-source software on your Mac.”

This effectively our charter and binary-only doesn’t fit.  The watchword at Apple is “a thousand no’s for every yes”.  IOW, focus on doing the right things really well and don’t get distracted trying to do all the other stuff just because it is possible.  Just because we _could_ provide binary packages doesn’t mean that we should.  

IMHO, YMMV, etc.

Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200806/9b8419cd/attachment-0001.htm>