On Sun, Oct 4, 2020 at 9:15 PM Ryan Schmidt <[email protected]> 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
