Is there a well-defined way to do "bleeding edge" ports? Should there be one?

[Ryan Schmidt]

On May 21, 2022, at 10:22, Bill Cole wrote:

> I'm currently working on a OSS project (SpamAssassin) which is in a pre-release rush and which I ultimately test & deploy via MacPorts.
> 
> I'd *like* to be able to switch from the current supported release in MacPorts to a fresh build from a Subversion checkout without manually mimicking what MP does (in part because I'm not 100% confident that I am doing it right) so that I can do testing iteration in a more efficient and repeatable fashion. This would be a different level of 'reckless cowboy' beyond the '-devel' ports we already have here and there with prerelease software.
> 
> I expect that this does not exist (I can't find anything...) but that it could. MP would need to always do a fetch/checkout/update/pull from the source control repo (I presume it would need BOTH svn and git support) and require use of a secure transport to make trusting the code without tarball checksums reasonable.
> 
> Does anyone else like the idea of this? See a need? Hate it? Already have a private tool for this?

MacPorts already supports fetching from most revision control systems including Subversion and git. Using this feature is discouraged but is possible. See https://guide.macports.org/chunked/reference.phases.html#reference.phases.fetch

The port must be written so that a specific revision or commit hash or tag from the revision control system is fetched. If upstream makes new commits and it is desired for the port to install that newly revised code, the portfile should be updated to reflect that, each time.

It is possible but not permitted to specify "the latest code" (such as a Subversion repository trunk or a git repository main or master branch or the head of any branch in any revision control system in fact) because if you did that, what one user received when they installed the port at one moment in time would be different from what another user received if they installed it at a different moment in time if there had been commits to that branch of the repository between those two moments in time, but MacPorts would not convey that difference in the output of "port installed", nor would "port outdated" convey to the user who installed the port first that any update were available. If the port is distributable, users would receive even older versions of the software from whenever the buildbot first built it.

Enhancing MacPorts to support some new notion of a port's outdatedness that would include network communication to a third-party revision control system has not been planned. It does not seem like a good idea to me. A fundamental concept in MacPorts is that a user has the assurance that at least one human has verified that a port builds successfully. Allowing the user access to arbitrary never-before-tested versions of the software is contrary to that.