MacPorts webapp project updates
Mojca Miklavec
mojca at macports.org
Fri Aug 14 14:02:22 UTC 2020
On Fri, 14 Aug 2020 at 15:10, Craig Treleaven <ctreleaven at macports.org> wrote:
> On Jul 12, 2020, at 2:55 PM, Arjun Salyan <arjun at macports.org> wrote:
>
>> Hello all,
>>
>> This is in continuation to my previous emails regarding updates about the webapp. The temporary version is deployed at http://macports.silentfox.tech/
>
> Is the temporary version of the new web app down at the moment?
Sadly yes. The free trial that Amar had expired a few days ago and we
are waiting for Amar to set up the app again on a new server (first
for testing and very soon after that for real).
> Does our new web app highlight which packages are available as binary installs?
Good point. We should be able to get that piece of information, but I
don't remember seeing that or having it on our roadmap. It would be
nice though, and probably not that much work to add this piece of
information.
> For example, version 3.16.0 of the port logrotate is available as a binary install for Darwin 10 through 19:
>
> http://packages.macports.org/logrotate/
>
> I imagine it would be more difficult to show that all the dependencies needed for a particular port are also available as binary installs.
It cannot be calculated once, in any case. A change somewhere deep
down in dependency chain could easily break binary distributability.
I also don't imagine an easy database call to retrieve this
information. So we would likely need a python function recursing
through the dependencies, and then this should be updated on regular
basis. It sounds a bit convoluted and probably not extremely high on
priority list.
On the other hand, maybe at some point we should be storing a list of
all dependencies of a particular port. Then, whenever any port is
updated, we would also update any port that has that one anywhere in
dependency list.
(Please note that we are only listing dependencies for the latest OS.
And even then we had potential issues with the server not running on
macOS and thus rendering a different list of ports. I think this has
been addressed, but it still means that a port that's distributable on
one OS may not be distributable on another one. Distributability per
OS could be done, but list of dependencies would require quite some
changes to the database. I was thinking about this problem from the
start, but I didn't want to overcomplicate the design of the app
itself.)
> Nonetheless, I think it might be worthwhile to show what _is_ available in binary. It would make an interesting top level statistic, if possible.
I agree.
> Of course, we ought to footnote somewhere that binary installs are only available if installing the default variant to the default prefix.
>
> The ongoing discussions about reinventing the ‘brew cask’ wheel suggested to me that perhaps we should better help users to understand that the majority of packages on MacPorts DO NOT have to be compiled on the user’s system.
I'm also still desperate about the problem with git (= I still fail to
understand why we must be almost the only package manager out there
that is not allowed to distribute git in binary form).
Mojca
More information about the macports-dev
mailing list