Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add coqPackages, idrisPackages, nodePackages, quicklispPackages to package list #228

Closed
wants to merge 1 commit into from

Conversation

ryantm
Copy link
Member

@ryantm ryantm commented Jun 30, 2018

I looked over all the package sets at the top level to find ones not in the current package listing; this change adds the coq, idris, node, and quicklisp sets. The uncompressed archive got 1 MB bigger from this change, and the compressed one got less than 100 KB bigger.

@vcunat
Copy link
Member

vcunat commented Sep 6, 2018

Well, alternatively we can consider actually building (some of) them: NixOS/nixpkgs#45849

@ryantm
Copy link
Member Author

ryantm commented Sep 7, 2018

@vcunat Is building them related to whether we list them?

@vcunat
Copy link
Member

vcunat commented Sep 7, 2018

Yes, they should get listed, at least if we use the usual recurseIntoAttrs to build them.

@ryantm
Copy link
Member Author

ryantm commented Sep 22, 2018

Are you saying that we should not list packages we do not build?

@samueldr
Copy link
Member

⚠️ not sure we should do this. Even thinking about proposing to revert the change for the packages listing on the website. If this is all for the popularity contest repology data source, we may want to generate those separately.

See #245

@ryantm
Copy link
Member Author

ryantm commented Oct 11, 2018

There are serious reasons to get this data into Repology, r-ryantm has some chance to update these packages, and we can receive more feedback about how our versions of these packages compare to other packaged versions that exist.

I'm only doing this PR to get the data into Repology, I personally don't care too much about it appearing on the website.

@samueldr
Copy link
Member

Yeah, and sorry if it sounded dimissive with the "popularity contest" joke. The ability to detect package issues is not to be overlooked.

I would even prefer having that data available to the end-users, but not at the cost of UX :/.

@davidak
Copy link
Member

davidak commented Jul 18, 2019

@samueldr do 100 KB really make a noticable difference for UX?

Merge conflict because the file was renamed to https://github.com/NixOS/nixos-homepage/blob/master/packages-config.nix

@samueldr
Copy link
Member

I don't really know. I'm not sure where the deeper performance issues lie. It's likely that there's just too much to index for the current approach at searching the package set.

I'm not sure I have the time to check using the developer tools the different between before and after this PR. If the effects are negligible, then I guess it should be fine. Though, I'm not sure what's a good target machine to test, a top of the line machine with ample ram is likely to get a different experience than a low-to-mid tier machine from a couple years back :/. And then, there's mobile use, which shouldn't be discounted, ideally.

@garbas garbas added this to Backlog in TODO Mar 29, 2020
@garbas
Copy link
Member

garbas commented Apr 14, 2020

I'm closing this PR but we will enable this subpackage lists in https://github.com/NixOS/nixos-search

@garbas garbas closed this Apr 14, 2020
@ryantm ryantm deleted the add-package-sets branch April 14, 2020 02:14
@garbas garbas moved this from Backlog to Done in TODO Feb 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
TODO
Done
Development

Successfully merging this pull request may close these issues.

None yet

5 participants