sublime4: drop openssl_1_1

[gepbird]

Tracking: #269713

I didn't mark it broken, because the core functionality seems to work, I can edit and save files. There's an annoying popup however: "plugin_host-3.3 has exited unexpectedly, some plugin functionality won't be available until Sublime Text has restarted" on launch.

Our options are:

• someone fixes this derivation without openssl_1_1. According to Upgrade OpenSSL sublimehq/sublime_text#5984 (comment), from 4200 (which we have in nixpkgs) we should be able to only depend on openssl_3
• mark the whole package as broken
• keep it at this half broken state

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[pwr]

There's a ST setting, "disable_plugin_host_3.3": true which stops the plugin_host-3.3 process from starting.
If that is set as a default preference, the plugin_host-3.3 binary could even be removed from the final package.

[jtojnar]

4200 only announced the deprecation, the old plugin host is still there for now.

Looking at 4200, it seems even plugin_host-3.8 crashes without `openssl_1_1.

For sublime4-dev (4205), it actually appears that removing the plugin_host-3.3 binary gets rid of the warning even without any settings change. Though doing so will disable packages, including those that are needed for core features (see that e.g. Edit → Sort Lines is grayed out). Fortunately, it looks like it is actually possible to include default settings into a package, which seems to fix that.

So I would be in favour of doing that and marking stable as broken:

diff --git a/pkgs/applications/editors/sublime/4/common.nix b/pkgs/applications/editors/sublime/4/common.nix
index be77793c7964..36e7a4b4896c 100644
--- a/pkgs/applications/editors/sublime/4/common.nix
+++ b/pkgs/applications/editors/sublime/4/common.nix
@@ -22,7 +22,6 @@
   writeShellScript,
   common-updater-scripts,
   curl,
-  openssl_1_1,
   openssl_3_5,
   bzip2,
   sqlite,
@@ -33,7 +32,6 @@ let
   packageAttribute = "sublime4${lib.optionalString dev "-dev"}";
   binaries = [
     "sublime_text"
-    "plugin_host-3.3"
     "plugin_host-3.${if lib.versionAtLeast buildVersion "4205" then "14" else "8"}"
     crashHandlerBinary
   ];
@@ -55,7 +53,6 @@ let
     libxtst
     glib
     libglvnd
-    openssl_1_1
     gtk3
     cairo
     pango
@@ -88,6 +85,8 @@ let
     buildPhase = ''
       runHook preBuild
 
+      rm plugin_host-3.3
+
       for binary in ${builtins.concatStringsSep " " binaries}; do
         patchelf \
           --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" \
@@ -95,6 +94,8 @@ let
           $binary
       done
 
+      echo '{"disable_plugin_host_3.3": true}' > Packages/Preferences.sublime-settings
+
       # Unable to get plugin_host-3.14 not crash with Python from Nixpkgs
       ${lib.optionalString (lib.versionAtLeast buildVersion "4205") "patchelf --set-rpath ${
         lib.makeLibraryPath [
@@ -223,6 +224,8 @@ stdenv.mkDerivation (finalAttrs: {
     ];
     sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ];
     license = lib.licenses.unfree;
+    # Packages, including core ones, do not run without plug-in host depending on insecure OpenSSL.
+    broken = lib.versionOlder buildVersion "4205";
     platforms = [
       "aarch64-linux"
       "x86_64-linux"

[jtojnar]

Thanks. Btw, you have atuhored in the commit message.

[jtojnar]

Actually, I wonder if we should perhaps mark the sublime4-dev broken as well to communicate it differs in functionality from upstream. Maybe something like

We have removed Python 3.3 package support ahead of upstream schedule but if you do not use any old packages, this should just work.

[gepbird]

Actually, I wonder if we should perhaps mark the sublime4-dev broken as well to communicate it differs in functionality from upstream. Maybe something like

We have removed Python 3.3 package support ahead of upstream schedule but if you do not use any old packages, this should just work.

I wouldn't want to mark it broken since most of the editor is working, but it sounds like an important enough change to emit a warning, I'm not sure how well the plugin ecosystem migrated to newer python.

[gepbird]

This should be deprecated, but weirdly it doesn't emit a warning by default.
I'm pretty sure removal means that the package in nixpkgs will be removed soon and not that we have removed a feature of the package.

Suggested change

	problems.removal.message = "We have removed Python 3.3 package support ahead of upstream schedule but if you do not use any old packages, this should just work.";
	problems.deprecated.message = "We have removed Python 3.3 package support ahead of upstream schedule but if you do not use any old packages, this should just work.";

[gepbird]

I think this is fine, the warning is not misleading:

warning: Package 'sublimetext4-4205' in /home/gep/nixpkgs/pkgs/applications/editors/sublime/4/common.nix:218 has the following problem: removal: We have removed Python 3.3 package support ahead of upstream schedule but if you do not use any old packages, this should just work. See https://nixos.org/manual/nixpkgs/unstable#sec-problems

Currently there's also meta.problems.maintainerless that also doesn't warn by default and fits even less for this use case, I wonder if it's worth adding something like meta.problems.modified for making modifications that are visible to users from upstream's distribution.

[gepbird]

CI is failing because this package newly emits a warning that is intended, cc @NixOS/nixpkgs-ci

[MattSturgeon]

CI is failing because this package newly emits a warning that is intended, cc @NixOS/nixpkgs-ci

Indeed, CI is intentionally strict about not allowing eval warnings, as usually that means something is wrong in the "default" package set. That's the main reason why aliases.nix exists, to gate warnings behind config.allowAliases. See also Silvan's comment w.r.t. channel blockers: #523892 (review)

In this case you're running into #523712, which #523892 is attempting to fix by teaching stdenv and CI about meta.problems.

[MattSturgeon]

Diff SGTM. The nitpicks don't necessarily need addressing, just LMK whether you plan to or not, so we know whether to wait before merging.

[MattSturgeon]

Same. I assume this is overwriting some default settings? It'd be nice to explain what and/or why.

Again from #531298 (comment), so cc @jtojnar for a wording suggestion