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 <[email protected]> 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
