Supporting installing arbitrary port versions

[Ruben Di Battista]

On Sun, Oct 4, 2020 at 9:15 PM Ryan Schmidt <ryandesign at macports.org> wrote:
>
>
>
> 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?

I was just suggesting it since that was the discussion flow. Then, I
expressed my own 2¢ opinion. :)

>
> > 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.

I read these. I understand the choices made at that time, but I think
~20 years later maybe they will be less applicable. For example, maybe
one of the aspects to take into account would be "newcomer
contributors friendliness", since I don't think most of the people
that want to contribute to Macports are proficient in TCL. I did not
run numbers, so I might be wrong. It's more likely they would be in
Python (just to say one), or Node.js, or whatever.


> 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?

Well, it's three character strings difference. But I find this
(https://github.com/spack/spack/blob/977117b502589886fb5833340ab6cf1c15b3b26e/var/spack/repos/builtin/packages/paraview/package.py#L139):

```
if version < Version('5.1.0'):
    [...]
```

way more readable than this
(https://github.com/macports/macports-ports/blob/d2acce23fbd523073731b27505a879385674f290/php/php-swoole/Portfile#L16)

```
if {[vercmp ${php.branch} 7.1] >= 0} {
[...]
}
```


Or also proper, expressive, readable OOP. Like:

```
class Paraview(CMakePackage, CudaPackage):
    """ParaView is an open-source, multi-platform data analysis and
    visualization application."""`
````

compared to the TCL version (that I don't even know if it would be
supported by Macports or not).

Or also a proper interactive debugger that could allow to step in
directly in the code and check the package manager status in that
right moment and speed up debugging instead of printing out things
around or reading the log after stopping the build in a specific
phase.


> 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?

Well, you can do lots of stuff also in x86_64 assembly too, probably
more than TCL, that does not mean it's an especially good fit for this
particular job or that it might exists better solutions w.r.t. certain
aspects today than 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.

I don't understand here, I'm not suggesting preventing installing
binary-only. I'm actually suggesting the contrary... Maybe I'm
misunderstanding your quote.

In any case what I wanted to say is that, if you go down the path of
installing all Portfile versions, a thing that I don't personally
endorse and like, it might be worth to see if you can leverage the
work of others, avoiding reinventing the wheel. And, on another,
wider, subject, I wanted to point out that maybe there are other
priorities that could be taken into account, like, for exemple,
choosing a language and ecosystem easier to pick up for newcomers.

That said, I'm reasonably fine with Macports like it is now, surely I
prefer it to Homebrew for reasons, and I'll keep using it. I just
wanted to drop my 2¢.



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