On Jun 22, 2020, at 09:59, Ken Cunningham wrote:
> Perhaps unavoidable in some cases, but if you look around the web, this is in
> fact the #1 complaint about MacPorts: bloat.
I can't corroborate that claim, but of course we are interested in reducing
bloat in MacPorts and welcome any suggestions or improvements toward that end.
For example, if the complaint is that multiple versions of perl or python3 get
pulled in during a build, we should fix that if we can by standardizing on a
particular version and/or by offering variants so that the user can choose the
one they want.
I admit I have been choosing not to add python3 variants in ports lately,
choosing instead to standardize on python38 as the version to use (since that
is the latest stable version and the one used by default in the python 1.0
portgroup); this is less work for maintainers since there are fewer
opportunities for something to break. I hope that this choice is satisfactory.
Some perceived bloat is unavoidable if we want to continue to following our
current practices. For example, if a port requires a perl module, then we use a
MacPorts perl and module port. Installing another copy of perl may be perceived
by the user as bloat since there's a "perfectly good" version of perl already
provided by macOS, but we don't want to pollute the user's system with perl
modules installed outside of MacPorts, so we keep our own perl and its modules
all self contained in our prefix. There's also the announcement from Apple that
we've mentioned before that scripting languages will not be preinstalled on a
future version of macOS, so it behooves us to prepare for the time when we will
need to use our own perl, python and other scripting languages even if we don't
need nonstandard modules.