Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[big!] Adds a completely re-made packages listing (explorer). #209
The code was previously present at : https://github.com/samueldr/nixos-packages-explorer
A demo (without the nixos website around): https://nix.samueldr.com/explorer/
This is a re-made packages explorer which is re-made especially to add features, with the idea to make it easier to add additional new features.
The page is built in a way that ensures a link to the page carries the state over; ensuring that someone following a link has the same view you have (as long as the channel data is the same).
Furthermore, this can (I think) close those issues
Though some of those were already fixed anyway.
Additionally, a change fixes this issue (though it wasn't a goal)
Unfree packages (#120 nixos#17126)
I do know that this is a thorny issue:
Though, I would like this PR not to be held up by this issue. If @edolstra so desires, I can remove the
I, though, personally am in favor of allowing the user to choose whether they see unfree packages or not, and defaulting to them not showing up.
The way they are show (more grayed-out
Broken packages (#120)
The feature is easy enough to add, if it is desired.
Though, for this, I would like to have opinions and inputs about how (after this is merged) this could be implemented. Additionally (just an idea off the top of my head) could the brokenness include metadata with a textual description of how the package is broken?
The application is built using preact, and as few other front-end dependencies as possible. The
Makefile and build integration
I'm not that used to writing Makefiles, I'm happy to
Other than that, I'm pretty sure the build integration is alright. I made sure not to need
It has been (partially) squashed through a rebase. It can be squashed even more if wanted.
Thanks for your work!
Here is a comparison:
Just some small notes:
The Ubuntu package search for comparison:
Different header for Nix page:
Looks bad because i used code for bootstrap 4.
Thanks for the review!
To reduce chances of misunderstanding, I have re-imported the
2. Long description
I have fixed the look for
3. Install command
I would need to have the most likely name for the channel available in the channel data json file, and use it instead of heuristically try to guess it some other way.
This wouldn't be really hard to add, so let's assume that it can be added and will be.
4. Platforms being empty
Ah! 18.09 changes the structure of the fields for
EDIT Oh my oh my, this may need some work on nixpkg's side. Here's what I get for
This is, uh, probably more verbose that what we want. We'll probably need some kind of "toString" that gives us something to print to the end-user.
5. Channel selection
Nothing is impossible, but the way I built it was to reduce the amount of information on-screen at once. Though it should be trivial to try out a different appearance (e.g. styled radio buttons; styled enough that the round button doesn't show up).
The goal is to make sure everything is accessible. E.g. the rows on the current listing aren't accessible using vimium (pressing F doesn't show a letter to access a row) or TAB-navigation. To smooth out the issue in the re-implementation I made sure to use an element that can be reached using keyboard-only navigation.
I'll (as the last thing to fix) look at alternatives to the select box.
@turion sorry for the delay, had a busy week-end. What do you mean "it loads slowly", is it stuck on the loading animation (three dots growing and reducing)? In that case, that means it's downloading.
My server does serve the file much slower than the nixos.org server serves the file. (2.18s vs. 0.511s!). Though, comparing the time after the channel data is downloaded, it doesn't look like it is slower to run.
Also note that there is an extra download that must be first done (+96ms here), which will always add the time for one server round-trip. That download is the list of channels that are available. This allows managing the available channels outside of the explorer's code.
It looks like the old website would cache the .json file and yours is not? That could account for the performance differences.
Also, if you don't get much response on this, be sure to email the mailing list. I think this is in the right direction on fixing stuff. Some people might think it is too much new code to maintain and maybe it needs its own repo/external link.
overall seems like a solid improvement - the current version is pretty barebones and also loads slow
Stack choice is familiar and I at least like it. in case you want to write some tests I like the Jest framework - jsdom gives you some great power to build non-fragile UI tests. also recommend prettier
long-term, not sure that loading the entire packages file is the best approach, especially when (1) there's pagination to show only 15 results and clicking on a separate distribution fetches another big file and (2) the file could grow far larger as time passes. ideally seems like you could efficiently filter the results and render the page on the server and then fetch the rest as needed when the client clicks thru pages. but I don't want to derail your work and not sure what the view around here is on a server
1200 kilobytes / 21 seconds = 57 kilobytes/s
don't have a ton of capacity to help but feel free to hit me up publicly or privately if you want to chat frontend
The current demo makes a new history entry on every button press, which means I had to go "back" in the browser like 20 times to actually get to the last website after playing around for a bit.
Yeah, though your argument is artificially limited to something you feel.
Let's dwell only on the pager previous/next page for now.
Here's a hill I'm prepared to get bruised on: the behaviour of a webpage shouldn't change because of the way the back-end has been architected. Following a link should add a navigation event to the history, and change the URL accordingly; the changed URL should load the site to work the same way if accessed directly.
Now: here's to the one issue I concede is a hard one to solve right:
The best solution I found from experience is to pop on blur1 (and on occasion, blur on enter press). It feels fine to me to expect that on blur, the user has "committed" the changes and is ready to peruse the results.
Not touching the history in that case will cause weird issues considering other actions touch the history. You would move back and forth into the history and be missing the first page of the results, it would be:
The "dumb" solution to this problem is to reduce the apparent functionality and force committing the change. Instead of live searching and updating the whole page, showing suggestions in another control/component, allowing completion, and then asking for an action (pressing enter, clicking a Search button) to commit the new search; thus pushing the new navigation event to "page 1 of new search".
1: blur, when the focus exits the field. Either by tab navigation, clicking elsewhere, etc.
Still waiting for comments from those in charge of the site. I'm still unclear as to whether the feature is desired, whether the implementation is fine, what needs to be done to upstream this. I pretty much haven't touched it at all since not knowing could mean efforts go in the wrong way with regards to what's desired.
I'm willing to polish this up any way desired, even re-do parts of it if needed, but I need some direction to do this.
This is really good work and I would be happy to merge the PR as is (once the merge conflicts are fixed).
In the long term, I would like to see the NixOS options, nixpkgs packages.json and manuals be published by the channel release script instead and have the nixos.org website be essentially a static page that loads the JSON using CORS. It would be nice if that was also tackled here but I understand that it would expand the scope of the PR.
When turning on unfree packages, I'm finding the contrast of an unfree package to be hard to read on odd zebra striped package details. The text is #666666, the background is F5F5F5. It does pass minimum contrast accessibility requirements, though, so I won't block on it.
About unfree software
The project's view about unfree software is known. We shouldn't promote unfree software.
This rewrite of the packages-explorer was written in a way that is easy to extend, and any part can easily be removed or tweaked as desired, including the filter for unfree software (which defaults to hide them). The cost of adding such a filter is much reduced compared to the previous codebase.
Still, my personal opinion is that it is a usability issue not to list unfree software in some way. Though, I do agree that we shouldn't promote unfree software, which is why they are gated under a toggle, and phrasing is added to every unfree software entry. The tone of that note was initially more neutral-to-negative by design.
Seeing that the foundation depends on unfree software, it seems weird to me to completely hide the presence of unfree software from the packages set, acting as if it didn't exist.
As a closing note, more details about my view. A part of Freedom, is the Freedom of choice, including the choice of using unfree software. We should better educate the user so they make an informed decision about their choice of using unfree software, and we can make it obvious what the position of the project is. Hiding the fact that the project has unfree software, while still packaging it is probably unwise, and does reduce usability for the users that have decided that the drawbacks of unfree software is worth it for their needs. Some users probably have skipped this distribution, thinking that they couldn't use some unfree software, possibly a hardware driver.