Remove unused class from sage_setup.optional extension

[tobiasdiez]

The code in optional_extension was mostly unused and is removed in this ticket (and similarly extension.skip_build was nowhere else set).
The only still used method was is_package_installed_and_updated which is moved to sage.misc.package.

Related: #28815

CC: @mkoeppe @kiwifb

Component: build

Keywords: sd111

Author: Tobias Diez

Branch/Commit: a7b1e81

Reviewer: François Bissey

Issue created by migration from https://trac.sagemath.org/ticket/31013

[sagetrac-git]

Changed commit from 508075c to 2492f1e

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

2492f1e

Code cleanup

[tobiasdiez]

Description changed:

--- 
+++ 
@@ -1,2 +1,4 @@
 The code in `optional_extension` was mostly unused and is removed in this ticket (and similarly `extension.skip_build` was nowhere else set). 
 The only still used method was `is_package_installed_and_updated` which is moved to `sage.misc.package` (where also a bit of typing info is added).
+
+Related: #28815

[mkoeppe]

comment:4

Can't make incompatible changes to the interface of a public function

[mkoeppe]

comment:5

(I'm referring to the list_packages function)

[mkoeppe]

comment:6

It's also conflicting with the changes in #30940 (which needs review)

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

649ffff

Fix build

[sagetrac-git]

Changed commit from 2492f1e to 649ffff

[tobiasdiez]

comment:8

Replying to @mkoeppe:

Can't make incompatible changes to the interface of a public function

So one cannot change public facing functions at all? What is the policy/strategy for this? Introduce a new method, say list_packages_typed?

It's also conflicting with the changes in #30940 (which needs review)

I wouldn't say it's conflicting, just results in easy-to-resolve merge conflicts.

[mkoeppe]

comment:9

Replying to @tobiasdiez:

Replying to @mkoeppe:

Can't make incompatible changes to the interface of a public function

So one cannot change public facing functions at all? What is the policy/strategy for this? Introduce a new method, say list_packages_typed?

It could be a new function (with deprecation for the old one), or an optional argument that controls the return type, ...

But in this particular case, it would probably be good enough to just give the new class dictionary-like behavior so that user code can continue to access the slots like a dictionary. Possibly with deprecation warning.