I made a bunch of badges for projects packaged on Nixpkgs to use.
These are meant to be like the Google Play Store, Apple App Store and Flathub badges.
Check them out!
(Sorry, font is weird right now)
Now fixed
EDIT: Check out my repo!
7 Likes
Why is the s of nixpkgs in the right border?
Since these are SVGs, I guess it might be a font issue?
It looks ~okay to me (and looks similar in Safari and Chrome):
I tried resizing the window and fiddling with zoom but neither ~broke them.
Ah. Yes it is. The font is meant to be Overpass. I will try to make the text into an object so this won’t happen.
1 Like
Probably font issue (send me a screenshot)
1 Like
I get this on OpenSuse Tumbleweed and OpenBSD in Firefox (I didn’t try another browser). Works fine in fedora 38.
1 Like
FYI I will fix font issues tonight (London Time)
Should be fixed now! 
3 Likes
I’m not sure… with distros there are really lots of them, so this size of badge seems big to me. I got reminded of e.g. knot-resolver packaging badges - Repology
A matter of taste anyway, I guess.
1 Like
The unique thing about Nix compared to, for example, Apt, is that it supports many operating systems and so IMO should have a large badge to reflect this (one large badge vs 10+ small badges).
EDIT: Shrunk the badge slightly as it is bit too big indeed. 
2 Likes
Sure, but so do Flatpak and AppImage, and I don’t think they get much special treatment either.
But I agree with the general premise of your idea. If a project generally wants to show packaging status for their repo, they will use the existing badges. If they maintain the package in nixpkgs themselves and/or want to show this off (maybe because they recommend nix as the default installation option) they can use this special, branded badge.
And this is very much in line with something like Flathub, where the developer probably wants to advertise this, as it reduces the potential amount of problems during installation.
Jup, looks good now (at least on iOS) 
But you may want to move the text down a little. It looks like you centered it mathematically, but visually it looks like the top margin is smaller than the bottom.
If you want to play around with something fun; you can actually include media queries in svg so you could make a version that is actually responsive to the user’s light/dark preferences.
3 Likes
Wow, I did not know SVG was this powerful.
1 Like
they can also be animated
Yes, see for example the tvl logo. Yhough I would say that might be overkill for the usecase od this thread 
My ultimate vision is that Nix will become the ultimate universal package manager for Linux (other OSes later). There can only be one universal Linux package manager (for it to be universal), and I want it to be Nix.
Hrm, I wonder if it would make more sense to state packaged with nix or for nix instead; Typically projects with nix support that are not maintained by third party maintainers inside nixpkgs come with a flake.nix or a default.nix, and I feel like that’s worth advertising more than that someone made a nixpkgs package for your project.
I for one definitely am more tempted to use something if I spot a flake.nix in its github repo.
Does anyone have thoughts on branding around that?
I would stick with Nixpkgs because it offers a more convenient experience.
However, I will add ‘Compatible with Nix’ badges later.
1 Like
Depends, right? Once flakes are commonplace, installing via the flakeref directly is the most direct way of distribution, but it’s still a source deployment.
Most people want to just use the software and so the most convenient and quickest deployment is a binary deployment, which is what Nixpkgs offers.
In those cases, the current badges make most sense.
For the source deployment case where people want to build/modify/hack a project locally, having a flake.nix or default.nix file is more important, but it’s a separate use caee that would warrant a separate badge. And I think I’ve seen that, actually 
Also depends on how commonplace cachix & co become. They seem to be getting quite pervasive, nix keeps nagging me about adding substituters for my flake inputs these days.
My worry with splitting this into two badges is that there absolutely are projects that have both, and it’s unreasonable to have two separate big badges indicating what is ultimately the same package manager. Having multiple subtly different badges targeted at users who will likely see but not understand the difference due to lack of exposure so far also seems somewhat counterproductive.
Ultimately marketing is above my paygrade, I just want to raise that the flake vs nixpkgs distribution model is something that should at least be considered for efforts like this.
I do like the badges idea though. I like spotting the flatpak ones in the wild, and IMO nix is close enough to that style of packaging format that it warrants having a badge
1 Like
True, but flakes are still officially unstable, and without flakes enabled, nixpkgs doesn’t behave any differently.
“Commonplace” was maybe a bad choice of word from my side. I meant “the primary and official way a user installs software packaged with nix”.