Dear Frank,
On Sun, 19 Jul 2020 at 00:27, Frank Schima wrote:
>
> Looks really good. I love dark mode!
>
> Some quick comments:
> - Remove all commas as a separator. A space works great.
What counts as "all"? For maintainers, variants?
> - Sort the variants alphabetically and also ports that depend on the
> currently selected port.
The variants could certainly be sorted, but dependencies seem already
sorted to me.
Unless you expected them to be sorted vertically rather than horizontally?
That's debatable, but copy-pasting gives you the correct order.
Or where (which port) do you see an issue with the list not being sorted?
> - Clicking on a variant does not really make sense to me. It seems to go
> back to the search page.
> The description of the variant should at least appear when you hover over a
> variant. Maybe they should not even be clickable links?
It gives you all the ports with a particular variant. Most of the time
this is useless, I agree, but there's also no reason to remove the
functionality now that we have it in place. There are rare occasions
where you would want to unify some functionality and then you might
want to check, say, how many ports use +doc and how many ports use
+docs etc.
(At some point we discussed whether having a clickable licence to show
all ports with the same licence made sense.)
The problem with variant descriptions is that this information is
missing from the PortIndex. Here's an example of the file used for
importing the port data:
http://nue.de.rsync.macports.org/macports/release/ports/PortIndex_darwin_18_i386/PortIndex.json
Arjun recently added MacPorts to the Dockerfile for the sake of being
able to run livecheck (and potentially other useful tasks like
generating the PortIndex more frequently than what the main server is
offering), so the built-in installation of MacPorts could potentially
be used to harvest the data about variant descriptions.
Maybe we could first import the list of all ports on the first
installation, then start harvesting information about variants once
the first import is done, and then update that information whenever
the Portfile is touched in git.
> - Python stub ports don’t really make sense. Search for, say, py-numpy.
> That’s a stub port. It should probably state that you would never install it
> - so don’t display “sudo port install py-numpy” for it because users should
> never actually do that in this case. But instead you want to pick py36-numpy,
> py37-numpy, etc. Show all of the real ports as clickable links. Currently it
> does not even allow you pick any of them.
We just discussed adding a clickable list of all subports today.
But how do you know that py-numpy is a stub port? By hardcoding a
function like the following [pseudocode]:
def is_stub_port:
return (path ~= "^python\/py-.*" and name ~= "^py-.*") or
(path ~= "^perl\/p5-.*" and name ~= "^p5-.*")
and adding more exceptions as they get discovered?
Arjun has only recently added the simplified overview with
instructions for installing a port. Until we had that page, having
non-modified pages for stub ports still made sense. And it still makes
sense in many cases now. For example, users should still be able to
add py-numpy to their watchlist to receive notifications about whether
that particular port has been updated. But I agree that we should not
confuse users by telling them to run "sudo port install py-numpy".
> - When clicking on the Trac tickets tab, I find it jarring that a window
> pops up that you have to click out of. Just make it a tab that displays the
> selectable tickets (or no tickets). I shouldn’t have to click “Close” to get
> out of this special mode.
We discussed the annoyance of clicking "Close" just today for another
button ("More ..." for getting the full description).
While I don't personally care that much, I also found it more useful
to see it displayed inside a separate tab as is the case on
https://ports.macports.org/port/py-numpy/tickets
for example.
Thanks a lot for the feedback!
Mojca
