About "where we are going", we are aware of some obstacles on the way. The most "worries" are on *packages that are named after a basic mathematical structure *as described in https://groups.google.com/g/sage-devel/c/kiB32zP3xD4. We see them expressed in https://github.com/sagemath/sage/pull/36964.
W1. What is the criterion of including a module in a *package*? Let us take (P) *sagemath-graphs* as an example. From the description of (P): (D) it's a package that defines graphs and recognizable generalizations thereof and contains code that directly makes use of such structures. Q1 Martin questions why sage.combinat.abstract_tree is in (P): https://github.com/sagemath/sage/pull/36964#discussion_r1564162445 Q2 Kwankyu questions why sage.knots is in (P): https://github.com/sagemath/sage/pull/38118#issuecomment-2141321507. (D) does not seem to clearly answer these questions. (D) may be an abstract way of expressing a technical criterion behind. If so, what is the technical criterion? W2. Does dissecting the sage library into pieces of *packages* prevent code in a module in a *package* from using code in a module in other *packages*? For example, Since *sagemath-graphs* is below *sagemath-standard-no-symbolics*, code in (P) cannot use symbolics? Q3 Martin fears that at some point there is a request not to use symbolics in some module, because Lisp is hard to install on some system: https://github.com/sagemath/sage/pull/36964#discussion_r1564914013 Take these as questions from the audience in the plenary lecture hall :-) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/92484327-9353-486b-8279-d80e5540d0dbn%40googlegroups.com.
