Supporting installing arbitrary port versions

[Ryan Schmidt]

On Oct 4, 2020, at 06:02, Ruben Di Battista wrote:

> Is this something that really needs to be implemented from scratch?
> There are other package managers that do this and are build to do this
> (nix and spack come to mind). I don't know the difficulties of what
> I'm going to propose, but wouldn't it be maybe easier to write a TCL
> Lexer/Parser that allows to translate the TCL files to input files for
> the other package managers and then tweak the `port` command to use
> those package managers under the hoods? I'm a bit closer to spack
> development, and they developed a concretizer
> (https://archive.fosdem.org/2020/schedule/event/dependency_solving_not_just_sat/)
> for the spec of the packages that took multiple years of work to be
> finalized.

So now you want MacPorts to become a wrapper around another system? That would be another colossal task, I don't know what the benefit of it would be, and it doesn't get us any closer to solving the previous colossal tasks I mentioned that stand in the way of being able to offer arbitrary versions and variants of all ports simultaneously, if that were something we wanted.


> Personally I don't like the idea of shipping all package versions,
> because there are already pieces of software developed for the same
> reason and that, possibly, will do a better job than whatever Macports
> will ever be able to do.

...then why are you suggesting the above?


> For me the Macports scope must be kept
> focused and small: installing (possibly latest versions of)
> open-source stacks from source keeping compatibility with old systems
> in the best way possible. There are already improvements that can be
> done  UX-wise keeping this same scope: two that come to (my) mind are:
> - Using another DSL/Language for Portfile that is easier, more
> flexible, and modern (e.g. Python)

https://trac.macports.org/wiki/FAQ#whytcl explains why Tcl was chosen.


For example, one benefit is the avoidance of a preponderance of symbols needed for basic tasks.

In its most pure form, a portfile sets variables to values. In Tcl with the way that MacPorts has enhanced it, that can be accomplished in the simplest possible way:

name zlib

sets the variable "name" to the string "zlib". Can you do it that concisely in Python? Don't you instead have to write:

name='zlib'

Isn't that going to get old really quickly when you have to set a dozen or more variables in each portfile?


Tcl is already as easy and flexible as anything, isn't it? What could you do in another language, that you would want to do in a portfile, that you can't do in Tcl?


> - Installing binary-only software.

MacPorts already supports this and we have several ports doing this. It would be impossible for MacPorts to prevent portfiles from being able to do this since portfiles are Tcl files with the full facilities of the Tcl language available to them, so they can do anything.