randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Ryan Schmidt]

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.