Before merging I want to take some of the changes of #55026 and integrate them here.

Before merging I want to take some of the changes of #55026 and integrate them here.

It'd be cool to also integrate the code style from there, in particular one item per line in arrays.
Not sure about removing the gtk option, but I already prefer having it on default here, maybe we should just remove it.

@worldofpeace Done, I left the arrays as-is because I don't like the 1/line look, if I must I will change it.

I simplified the makeDesktopItem and patchelf stuff, I'd like a suggestion on how to lift the default-toolkit selection off of the script portion, it looks dirty and it's hard to read.

I mean the

    "--enable-default-toolkit=cairo-gtk${if gtk3Support then "3${lib.optionalString waylandSupport "-wayland"}" else "2"}"

line.

@worldofpeace Done, I left the arrays as-is because I don't like the 1/line look, if I must I will change it.

I simplified the makeDesktopItem and patchelf stuff, I'd like a suggestion on how to lift the default-toolkit selection off of the script portion, it looks dirty and it's hard to read.

I mean the

    "--enable-default-toolkit=cairo-gtk${if gtk3Support then "3${lib.optionalString waylandSupport "-wayland"}" else "2"}"

line.

You could put it in let in

let 
  toolkitSlug = if gtk3Support then ''
    3${optionalString waylandSupport "-wayland"}
  '' else "2";

  toolkitValue = "cairo-gtk${toolkitSlug}"
in

This also reminds me that waylandSupport logically implicates gtk3Support.

@worldofpeace Not sure why the eval is borked

I've been using current state (601b08d0) for a couple hours, and it seems fine. (But I haven't really looked at the code, so far.)

It'd be cool to also integrate the code style from there, in particular one item per line in arrays.

I agree the style does have some advantages, but to me it takes a bit too much space typically and I personally prefer to group them a bit. BTW, that PR did this only for *Inputs and not for the function parameters; I assume you'd want to apply one-item-per-line in there as well, as that's what I see in gnome expressions.

In any case, I don't care much and I want to avoid spending noticeable amount of time on bikeshedding discussions.

How about I just nixfmt it and call it a day?

* remove `MOZ_LEGACY_PROFILES`

* remove `MOZ_ALLOW_DOWNGRADE`

(on the advice of upstream maintainers)

I think that will get us into a funny position. At least for Firefox it treats each new binary location as an incompatible install of Firefox and thus refuses to reuse your existing profiles. That is why those are in there. If you recompile the package with a few bits flipped you should be able to reproduce that.

@andir I expected that too, but in my testing so far I have been unable to reproduce that and things work fine. It'd be nice if someone else would confirm no issues, cc. @vcunat

I agree the style does have some advantages, but to me it takes a bit too much space typically and I personally prefer to group them a bit. BTW, that PR did this only for *Inputs and not for the function parameters; I assume you'd want to apply one-item-per-line in there as well, as that's what I see in gnome expressions.

Yeah, this happens to be how we've chosen to go about things in gnome expressions.
And using nixpkgs-fmt, I really value diff-ability. Even if the files are long.

I believe I did encounter some issues with thunderbird refusing to "downgrade" or something like that, at least when switching testing of -bin and compiled variant (even though my version never decreased). That was just before we merged some of these variables IIRC (several weeks ago?)

I really value diff-ability

Yes, but regardless of this I personally want to use tools that nicely highlight smaller changes on longer lines. (For non-nix code, for example.)

I reverted the changes around legacy profiles for the time being, if they complain during the standardization process we can revisit this.

@worldofpeace, @vcunat, @andir: This is ready for a last look and merge.

@lovesegfault Could you document all the notable changes in the commit msg?

@worldofpeace on it :)

@worldofpeace done!

@worldofpeace once you are happy with functionality/testing/reviews feel free to merge. Nothing against it from my side. Just do not use use it so testing it would be kinda silly...

Pushed silly nitpicks and the new homepage https://www.thunderbird.net/en-US/

Thanks a lot @lovesegfault 🌠
Was nice helping you, thanks for the commits.

Thanks everyone for helping me push this through :)