Fix/wrong colors status labels & nix buildingShell devShell not allowing to build cartero due to missing dependencies

[AlphaTechnolog]

This pull request addresses #83 where all the problem itself is being detailed, but in resume it's just that when cartero gets a non success status on a request (e.g: 400, 500), it will change the label to red/yellow depending, which is ok, but after that if you get again a 200 status, it won't just update its color to green again, which was being caused because the warning or error classes were overriding the success one since nothing was cleaning them up resulting in a label with every class, and the one with the most level of priority was the one that was overriding every other one.

What this PR does is cleaning all the classes if found before adding the new class to the label, which seems to do the trick, but im open to any change or any suggestion to improve the code 😁

Another thing this pull request does is to fix the devShell which wasn't being able to manually let me build cartero for dev purposes, which was being caused by glib not being pulled and others, this pr addresses that one too.

[AlphaTechnolog]

About the tests failing, looks like blueprint compiler changed the repository? if you run git clone https://gitlab.gnome.org/jwestman/blueprint-compiler nowadays, it will just fail with this

fatal: unable to access 'https://gitlab.gnome.org/jwestman/blueprint-compiler/': The requested URL returned error: 503

which is the error in the failing tests, also if you go to that repo, it will just say the repository does not exists? looks like they removed it.

[AlphaTechnolog]

ah no looks like whole gnome.org is down lmao

[danirod]

Yeah, I believe that GNOME services have had some problem recently, last week the forums were offline too.

I'm running the pipelines again hoping that the response is different this time.

[danirod]

Looks good. I think this PR may explain why sometimes the status code appeared yellow rather than green. I always assumed this was a bug on the GTK theme used on Windows! 😄

[danirod]

I have a somehow unrelated question here.

What's the difference between default.nix and flake.nix? I remember that some dependencies were added to default.nix back in #44.

Learning Nix is still on my to do list, but are there some cases where default.nix is preferred over flake.nix?

[AlphaTechnolog]

Well yeah it all depends on how you structure the nix implementation for your project, for cartero i tried to do it in a way similar to how i've seen in anothers projects ppl already did it, which is, using a flake.nix to create dev shells (environments where you get automatically all the dependencies for building your project), and exposing packages (so ppl can do in their terminal per example, nix run github:danirod/cartero and it will run cartero by downloading everything in one command (this actually works btw)) so the thing here is that im adding those dependencies aswell for the dev shell, so i get an environment to be able to build cartero manually by using meson setup build -Dprofile=development myself

The thing is that for some reason i had forgotten to add these aswell here before when i packaged this for nix? idk lmao but in any case this will do the trick

so in resume for this project

1. we've flake.nix to expose dev shells and packages (the package is the one that ppl merges in their environment.systemPackages by using inputs.cartero.packages.x86_64-linux.default), in the dev shell i wanna get an environment where i get a development build of cartero and the dependencies to manually build it
2. we've default.nix which is the cartero derivation, which defines all the steps to build cartero to nix. It's probably not as explicit to say which commands it should run because pkgs.rustPlatform already got some abstractions around that, and also the meson hook (runHook meson line) which automates it a little bit.

[AlphaTechnolog]

There're also others ways to packages nix projects without flakes (which is starting to be the preferred way) over nix channels, which is the older way... you may wonder why nix flakes over nix channels? nix channels requires user intervention for managing them, they'll define an upstream url and the user should manage them manually to switch to nixpkgs unstable or nixpkgs stable when the project requires it, with nix flakes you can define as the project maintainer which one to use, and which one your nix dependencies (third party projects) should follow, either it's unstable, stable, or even a nixpkgs fork

The legacy packaging usually used to look somehow like this

• shell.nix:

{ pkgs ? import <nixpkgs> {}, ... }: pkgs.mkShell {
  buildInputs = [...];
}

Inside mkShell it's basically the same as i did in the flake.nix, in fact i could make a legacy dev shell and then import it in my flake.nix so we get support for both legacy dev shells, and flakes based shells. Note that the ? import <nixpkgs> {} expr, means that the pkgs parameter, if not passed by no one, it will default to the result of importing nixpkgs (and around <> means from a nix channel)... this is similar to the expression i did in flake.nix that looks like this pkgs = import nixpkgs {inherit system overlays;}

• default.nix: Which is basically the same as i did in the default.nix we've, but probably by tinkering a little bit around that pkgs parameter because we would have to use nix channels to import them.

[danirod]

I am totally taking notes of this.

(I think that if I just get an Ethernet cable and a wired connection I could skip the "can't learn NixOS because can't setup the wifi on the NixOS I've just installed" phase)

[AlphaTechnolog]

@danirod how's that? have you got a weird wifi driver or something like that? i remember having such issue with a wifi dongle which didn't support in some older kernels, but in fact if you just enable networking.networkmanager.enable = true when installing nixos, it will add wifi support for the system when installing it, that ofc if the kernel has the drivers for wifi support on your system. If using calamares i am not sure tho, but you could follow the manual installation instructions via /mnt/etc/nixos/configuration.nix file and the nixos-install cli tool inside the livecd.

[danirod]

I still don't know the reason. Naively I think that using NetworkManager is cheating, because then the network config would not be declarative. (It's fair to say that a declarative wifi config could be unsafe if not done properly, specially because PSK keys.) However, it seems to ignore me when I rebuild the system. Further research is still needed.