Supporting installing arbitrary port versions (was: Re: port "cask" -- installing prebuilt binaries)

[Ryan Schmidt]

On Oct 3, 2020, at 06:05, Lothar Haeger wrote:

>> It's because, besides being an unimaginably large amount of work in rearranging our code to do it, I have absolutely no idea how it would be accomplished without providing the user with unlimited opportunities to create broken combinations of port versions, which would generate an unlimited number of bug reports that we would then need to respond to, and my goal in MacPorts is to reduce, not increase, the likelihood that users would find something broken or need to contact us to help troubleshoot it.
>> 
>> If you have an idea for how it could be done without such problems arising, please open a new topic and describe it and we can talk through a few scenarios and see if it works.
> 
> I do have some ideas (not mine, just looking at how it works elsewhere), but not the time to drive something of this size, to be honest. Basically, we'd need to 
> - keep and distribute all Portfile versions (including patches and files), not just the lastest
> - add required versions to dependencies (can be version ranges e.g. >=1.2.3 or 2.* or 1.2.3-4.5.6)
> - add support to install individual ports in into separate folders or give them individual names on install time (much like with the perl versions), so multiple versions of a port can be installed in parallel.
> - add command line parameters to the port command so users can optionally specify a version to install (defaults to latest) and a pre/post fix to install location or file names or both (depends on how stuff gets implemented, of course)
> - add support for dependency resolution including version information. So if two ports have different, non overlapping version requirements for a dependency, that dependency gets installed twice. Making sure each port then actually uses its matching version is probably one of the trickier parts here.
> 
> Implementing all this would be a major project and I totally understand that it's nothing to jump at without considering all the consequences and outside factors. 

It would be a major project if it were clear how it could possibly work and it were just a matter of doing it. But so far I have no idea how it could work.

Just looking at your idea to distribute all portfile versions, let's start with the fact that portfile syntax has evolved over time. A portfile from ten years ago can't even necessarily be parsed by today's MacPorts ("livecheck.type" used to be called "livecheck.check"; there used to be "cd" and "suffix" procedures that ports used to use) or it may behave differently than it did then ("platform" blocks used to behave like variants and their code was evaluated at the end of the portfile rather than where it's declared; the way that the arguments of startupitems and configure.env/build.env/etc need to be quoted was changed).

Libraries change over time. Sometimes when a library changes it means that the other ports that use that library need to be patched. Obviously those patches were not in the old versions of the portfile that predate the new library, and patches for the current version of the software couldn't necessarily be used on old versions without being rewritten.

Compilers and operating systems evolve. Xcode 12, for example, prohibits implicitly declared functions. We're adding patches to ports as fast as we can to fix these problems, but old versions of the portfile would not have those patches.

If MacPorts allowed the user to pick an arbitrary old Portfile to install, it is extremely likely that the user would experience an error.

If you are suggesting that we should not only distribute all old portfiles but also keep them all updated as needed, that would be a ludicrous amount of work that nobody would be willing to do.


>> I'm speaking of the user being able to specify an arbitrary version.
> 
> So do I.

Well you spoke of keeping all Portfile versions. So perhaps you're suggesting the user should be able to select from any past version of the port. That's slightly more reasonable than allowing the user to request any version of the software regardless of whether that version has ever been in the portfile, but still completely impossible and unsupportable as far as I can see so far.


>> I consider it a feature, not a bug, that we offer multiple ports for different versions of perl, php, python, ruby, gcc, clang. It enables the user to install multiple versions of those languages that can all be active and available at the same time. If the user has one script that works with python 3.8 and another that requires python 3.6, no problem. If they have one web site that works with php 7.4 and another that needs php 7.2, no problem. If we only had a single python or php port that only let the user choose a single version to install at a time, that would not be possible.
> 
> I totally agree that this is a great feature. Only it's limited to a few versions of a few ports due to the way it's being implemented. Supporting this for more ports and version does not scale well, twice as many ports/versions cause twice as much work. With thousands of ports in the tree the current approach will always be limited to a handful of ports.

Exactly: it's a lot of work to implement it correctly, which is why it's only done for a few ports where it's really useful.

> If this was implemented as general features to a) install any port version and b) install several instances of any port, we'd get the same for each and every port/version out of the box.

I have no idea how the manual labor that we currently expend on implementing this feature selectively could be automated or generalized to all ports.