Opened 16 years ago
Closed 5 years ago
#19300 closed enhancement (fixed)
ports.php: web site should have page about each port, not link to portfile
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | website | Version: | |
Keywords: | Cc: | cooljeanius (Eric Gallager), mojca (Mojca Miklavec) | |
Port: |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
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 (13)
comment:1 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
comment:2 Changed 16 years ago by jmpalacios (Juan Manuel Palacios)
comment:3 Changed 16 years ago by jmroot (Joshua Root)
Aren't the limitations of ports.php exactly why we want to have MPWA?
comment:4 follow-up: 5 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
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.
comment:5 Changed 16 years ago by jmpalacios (Juan Manuel Palacios)
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
comment:6 Changed 16 years ago by (none)
Milestone: | Website & Documentation |
---|
Milestone Website & Documentation deleted
comment:7 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
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.
comment:8 Changed 12 years ago by cooljeanius (Eric Gallager)
This issue was sent to me via email by Mojca Miklavec.
As in #19298, if Mojca brought this up, mojca@… should probably be cc-ed on this issue, right?
comment:10 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | mojca@… added |
---|
comment:11 Changed 10 years ago by mf2k (Frank Schima)
Cc: | mojca@… added; mojca@… removed |
---|---|
Owner: | changed from jmpp@… to macports-tickets@… |
Type: | defect → enhancement |
jmpp is no longer active. See #44809.
comment:12 Changed 5 years ago by FranklinYu (Franklin Yu)
If I understand correctly, this is resolved.
comment:13 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Yeah, the new macports-webapp is the resolution to this.
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.