On Wednesday, April 24, 2024 at 2:26:37 PM UTC-5 Oscar Benjamin wrote:

Thanks Marc. This seems like a good example of a useful part of Sage 
that can be extracted to something much smaller than Sage. 

Presumably though a hypothetical person who wants CyPari2 but not all 
of Sage can already just use CyPari so that person is already well 
served. 


Correct.
 

Is the plan that CyPari2 would effectively replace CyPari? Then the benefit 
is not needing to maintain CyPari separately from 
sagelib's CyPari2 dependency?


No, rather CyPari is an example of the sort of free-standing Python package 
that could be extracted from Sage.  Modularization would create more of 
these, in varying sizes and levels of granularity.

Some level of modularization is necessary to address what William Stein 
described last year as:

*The fundamental and massive problem that I think SageMath has is that it 
is not part of the  Python ecosystem,*
*by which I mean that there is no good way to do "pip install 
sagemath-[foo]", in sufficient generality.*

*PROBLEM: SageMath is not part of the Python ecosystem.*

*DEFINITION: A piece of software is part of the Python ecosystem, if you 
can do "pip install <software-name>" on*
*basically the same platforms as the intersection of where you can install 
scipy/numpy/matplotlib/pandas,*
*and with somewhat comparable resource usage (i.e., installing Sagemath 
can't use 100x of the time/space of*
*the above, as that would be unfair).*

On a related note, the reason that CyPari2 and CyPari are still separate 
relates to what Marc mentioned earlier about tension between two models of 
installing software: the "Linux distro way" using a system-level package 
manager (where there is typically only one version of any given library on 
the system) and the "Python pip" way (where all needed libraries are 
statically linked into the wheel).  CyPari2 follows the first, CyPari the 
second.  (This story is further complicated by the fact that, from a user's 
perspective, conda is like "Python pip" in that it is orthogonal to any 
system libraries, but developing packages for conda is akin to building 
them for a Linux distro.)

Of course, most projects in the scientific Python community support both 
models, but there is technical overhead in doing so, which I believe is the 
root of some of the current conflict.

Best,

Nathan

-- 
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/60a60056-f8e9-417e-b03a-1dcfcbc3c6ebn%40googlegroups.com.

Reply via email to