Supporting installing arbitrary port versions

[Ruben Di Battista]

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.

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. 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)
- Installing binary-only software.

just my 2¢

On Sun, Oct 4, 2020 at 7:58 AM Joshua Root <jmr at macports.org> wrote:
>
> On 2020-10-4 16:36 , Ryan Schmidt wrote:
> > On Oct 3, 2020, at 23:40, Jason Liu wrote:
> >
> >>> Just looking at your idea to distribute all portfile versions, let's start with the fact that portfile syntax has evolved over time.
> >>
> >> This is where portfile syntax itself can, and probably should, be versioned. Maybe by incrementing PortSystem? i.e. PortSystem 1.3, 1.4, 2.0, etc. Similar to how the HTML standard specification's version number has changed over time, from HTML 2 all the way to the current HTML 5.
> >
> > Yes, we could do that starting now, but since we haven't up to now, the problem exists. The portsystem version concept was part of the original MacPorts design, predating the involvement of everyone here, so we would have to figure out how it works, whether it was ever fully implemented, what the implications would be of increasing the version, etc.
>
> It is implemented to the extent that "PortSystem $version" is a proc
> call that runs "package require port $version". Keeping support for old
> Portfiles would require keeping around old versions of the port package
> and the other packages it requires, with the old code that the old
> Portfiles rely upon (including problematic code; this would need to be
> "bug for bug" compatibility.)
>
> Linux distros don't support building their old packages from source in
> arbitrary newer environments, they just let you install the package.
> Given compatible versions of all the dependencies, that usually works,
> because they are an entire OS and so they're targeting the Linux kernel
> ABI which is quite stable.
>
> - Josh



-- 
          _
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜       |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `'
https://rdb.is