New Ticket     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #19300 (new defect)

Opened 3 years ago

Last modified 4 months ago

ports.php: web site should have page about each port, not link to portfile

Reported by: ryandesign@… Owned by: jmpp@…
Priority: Normal Milestone:
Component: website Version:
Keywords: Cc:
Port:

Description (last modified by ryandesign@…) (diff)

Currently ports.php lets you search for a port, but once you click on one for more info, it just takes you to the portfile in the repository. Users should never need to see the portfile text. Instead, we should show a nicely-formatted page which would include the information you can see in such commands as "port info" and "port variants"

James Berry  brought this up back in 2005.

This issue was sent to me via email by Mojca Miklavec.

Change History

  Changed 3 years ago by ryandesign@…

  • description modified (diff)

  Changed 3 years ago by jmpp@…

I've never really liked the ports.php page much either. Other than the ugly layout of the PHP code, mixed all over with SQL, uuggghhh... it's utility is rather limited, I'd say. Reason why I didn't do much about it at the time, though, other than limited available time, is that what I had in mind to boost its appeal was by no means a non-trivial addition. I thought clicking on a port result should take you to a page displaying the port's current build status on all the platforms we support, as gathered from the build logs of automated runs (produced by LoggingProposal) and processed by a webapp (mpwa). Neither of those two key components have been implemented yet, though, so a short term alternative could be a simple as removing the anchor to Trac's source browser. Thoughts...?

-jmpp

PS: If anyone would believe me, I'm still pretty much interested in implementing LoggingProposal, though my current commitments are still keeping me from engaging in any extra curricular activities, unfortunately.

  Changed 3 years ago by jmr@…

Aren't the limitations of ports.php exactly why we want to have MPWA?

follow-up: ↓ 5   Changed 3 years ago by ryandesign@…

It looks like MPWA hasn't been touched in 2 years. We don't have it running on the server now, and back when we did, it looked pretty unfinished, at least visually. MPWA is written in ruby, a language I don't know and don't have time to learn and master.

MPWA seems much more ambitious than just a better display of port info. It seems to aim to provide information about automated port builds, which we don't have, and to provide mechanisms to allow users to submit and vet new and updated ports.

The MacPorts web site is written in PHP, a language I have used for close to a decade and know inside and out. It will not be a problem for me to implement the changes requested in this ticket, to solve the immediate problem. This does not preclude reviving MPWA later.

in reply to: ↑ 4   Changed 3 years ago by jmpp@…

The MacPorts web site is written in PHP, a language I have used for close to a decade and know inside and out. It will not be a problem for me to implement the changes requested in this ticket, to solve the immediate problem. This does not preclude reviving MPWA later.

No, not at all. Current ports.php and logging/automated-builds/mpwa are really two different beasts and the former is unfortunately a pretty distant one. And I think we could all agree that ports.php could use some immediate improvements.

-jmpp

  Changed 3 years ago by anonymous

  • milestone Website & Documentation deleted

Milestone Website & Documentation deleted

  Changed 4 months ago by ryandesign@…

A concern raised in #29935 is that the per-port web pages should make it clear what other ports will be installed, and not just list the immediate dependencies. Some ports have a surprising number of rdeps.

Note: See TracTickets for help on using tickets.