date:20240423

On Tuesday, April 23, 2024 at 8:58:58 PM UTC-5 Dima Pasechnik wrot

It's not quite correct to say that a C, or other, compiler is not required
to run Sage. Sage allows you to define, build, load, and run Cython
extensions without leaving Sage, thus, it needs to call a compiler after
cythonisation step.

It's another question why it's called on startup.

Yes. If a user were trying to compile cython code on a machine with no
compiler it would make sense to post a warning and offer to install a
compiler. But it does not make sense to impose that warning and offer on a
user who is not doing anything that needs a compiler.

Might be macOS - only ?

The xcode-select behavior is macOS only, of course. But the code block
that Gonzalo pointed us to is run for *every* invocation of Sage on every
platform. Its purpose is to determine whether the platform has
non-standard names for the gcc assembler, linker or archiver, which
evidently can occur in some rare cases. It does this by calling $CC with a
gcc-specific option which returns the name of one of these utiltiies (if
$CC happens to be gcc). While this is done for every invocation of sage,
it is seems to be intended primarily for the sage -i command.

I wonder if the Sage community would be willing to reconsider the idea of
having one entry point for every function provided by SageMath, with
options determining which function is actually invoked. This was a popular
way of doing things at one time, but has been unfashionable for years as
one can see, for example, by running man mkfs on linux.

Instead of having a single executable named sage with options like sage
-python, sage -pip, sage -i, sage -gap, sage -singular etc. there could be
separate executables: .sage, sage-python, sage-pip, sage-install sage-gap,
sage-singular. I think this would be clearer and simpler to implement. It
would be easier to make sure that only needed initializations are done -
avoiding asking gcc for the name of its linker just because someone wants
to run pip, for example.

- Marc

--
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/c713bdb5-6112-4d7c-91cf-a56d01aaa2f4n%40googlegroups.com.

[sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

That was it!

Thank you Gonzalo; indeed, it helps a lot.  And your workaround is fine, 
since we don't support the -i option,  Even if we did, the default names 
for as, ld and ar are correct whenever the command line tools are 
installed.  So that block of code is completely irrelevant for the macOS 
platform.  This solves the problem.

- Marc



On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:

> https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and 
> L494
>
> See: https://github.com/sagemath/sage/issues/14296 and 
> https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a
>
> Maybe you can workaround this by setting AS=as and LD=ld in 
> sage-env-config.
>
> HTH,
> Gonzalo
>
>
> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote:
>
>> I discovered, by installing the Sage_macOS app on a pristine macOS 
>> system, that somehow, somewhere, in Sage's startup sequence there is a call 
>> to gcc.  This is true whether Sage is being started from a command line or 
>> a notebook.
>>
>> On such a macOS system /usr/bin/gcc exists, but calling it causes a 
>> dialog to be posted which asks whether to download and install the Xcode 
>> "command line tools".
>>
>> There is no need for a user to install, or be prompted to install, a C 
>> compiler in order to run Sage.  If we want to verify whether a C compiler 
>> is installed on the host system then we should check the return value of 
>> xcode-select 
>> -p rather than calling /usr/bin/gcc.
>>
>> I am unable to find where this call occurs.  Do any of the Sage 
>> developers know which component of Sage could be calling /usr/bin/gcc on 
>> start up?
>>
>> - Marc
>>
>

-- 
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/1fe1fca2-f228-45eb-9f43-a1d1be5d5895n%40googlegroups.com.

[sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

2024-04-23 Thread 'Gonzalo Tornaría' via sage-devel

https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and L494

See: https://github.com/sagemath/sage/issues/14296 and 
https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a

Maybe you can workaround this by setting AS=as and LD=ld in sage-env-config.

HTH,
Gonzalo


On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 Marc Culler wrote:

> I discovered, by installing the Sage_macOS app on a pristine macOS system, 
> that somehow, somewhere, in Sage's startup sequence there is a call to 
> gcc.  This is true whether Sage is being started from a command line or a 
> notebook.
>
> On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
> to be posted which asks whether to download and install the Xcode "command 
> line tools".
>
> There is no need for a user to install, or be prompted to install, a C 
> compiler in order to run Sage.  If we want to verify whether a C compiler 
> is installed on the host system then we should check the return value of 
> xcode-select 
> -p rather than calling /usr/bin/gcc.
>
> I am unable to find where this call occurs.  Do any of the Sage developers 
> know which component of Sage could be calling /usr/bin/gcc on start up?
>
> - Marc
>

-- 
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/4957e41d-2d1b-4714-856c-40e718004388n%40googlegroups.com.

Re: [sage-devel] Question: why does /usr/bin/gcc get called during Sage startup?




On 23 April 2024 19:48:18 BST, Marc Culler  wrote:
>I discovered, by installing the Sage_macOS app on a pristine macOS system, 
>that somehow, somewhere, in Sage's startup sequence there is a call to 
>gcc.  This is true whether Sage is being started from a command line or a 
>notebook.
>
>On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
>to be posted which asks whether to download and install the Xcode "command 
>line tools".
>
>There is no need for a user to install, or be prompted to install, a C 
>compiler in order to run Sage.  If we want to verify whether a C compiler 
>is installed on the host system then we should check the return value of 
>xcode-select 
>-p rather than calling /usr/bin/gcc.
>
>I am unable to find where this call occurs.  Do any of the Sage developers 
>know which component of Sage could be calling /usr/bin/gcc on start up?

It's not quite correct to say that a C, or other, compiler is not required to 
run Sage. Sage allows you to define, build, load, and run Cython extensions 
without leaving Sage, thus, it needs to call a compiler after cythonisation 
step.

It's another question why it's called on startup.
Might be macOS - only ?

Dima

>
>- Marc
>

-- 
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/196ECB9F-6E79-4FEB-A928-9C20BCF7F673%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)




On 23 April 2024 19:13:44 BST, Matthias Koeppe  wrote:
>On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote:
>
>
>
>On 23 April 2024 18:41:34 BST, Matthias Koeppe  
>wrote: 
>>*$ git blame src/sage/combinat//designs/block_design.py* 
>> 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 65) 
>>lazy_import('sage.libs.gap.libgap', 'libgap') 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 66) 
>>lazy_import('sage.matrix.matrix_space', 'MatrixSpace') 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 67) 
>>lazy_import('sage.modules.free_module', 'VectorSpace') 
>>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 68) 
>>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>>'FiniteField') 
>> 
>>What you see there is the result of work in the modularization project, 
>>using one of the techniques documented 
>>in 
>https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages
> 
>>("Reducing module-level run-time dependencies:") to reduce dependencies or 
>>to make dependencies milder. 
>
>The problem is that without these imports, lazy or not, this module is 
>basically useless.
>
>
>That's correct, but that's not a "problem". 

It is a problem, because such a module doesn't do what is says on the label.
Basically such a module is a semi-random part of sagelib, and it would not be 
fully functional until one installs a good chunk, probably well over half, of 
sagelib.

I am not saying it is totally useless, this sort of partition, but I don't see 
the point of distributing such  pieces, as Python wheels, as something useful 
on their own.

Application builders - who, according to Marc, are the only ones to get 
benefits from this design - can just as well build the needed part of sagelib 
from source, they don't need these barely useful wheels.



>
>It's part of a deliberate design, explained in detail in my 2023-06 
>sage-devel posts. 
>
>From "*Modularization project: IV. The rules*" 
>(https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s):
>*3.* Distribution packages declare build dependencies and runtime 
>dependencies 
>
> (on 
>other Python distribution packages). These two can be entirely unrelated to 
>each other. In addition to the runtime dependencies, it is possible to 
>declare extra dependencies – either those necessary for running tests 
>
> or 
>for providing advertised  
>
>extra  
>
>features 
>.
> 
>But there is no such thing as an "optional build dependency" or 
>"conditional compilation". The set of modules that form a distribution 
>package is static. There is no place in the name (or metadata) of a wheel 
>package that could indicate different "configurations".
>
>*4. *As a result of 3, it is possible to create distributions that contain 
>some modules that cannot be imported because some of their dependencies are 
>missing. That's OK; they can become importable simply by the presence of 
>other distributions, in particular those declared as extra dependencies. 
>All of this is discovered at the time of importing a module; there is no 
>ahead-of-time linking step of any sort.
>
>From "*Modularization project: V. The blocs*" 
>(https://groups.google.com/g/sage-devel/c/kiB32zP3xD4):
>*We should not attempt to define a distribution package for every possible 
>community or subfield of mathematics that Sage supports.*
>The proposed design instead introduces 3 types of distribution packages: 
>[...]
>Each of the distribution packages can define a list of extras (nicknames 
>for sets of other distribution packages that provide additional advertised 
>features). When using pip to install a distribution, users can use square 
>bracket notation to add (adjoin?) these extras.
>
>

-- 
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/6AAFD6C9-15B8-4ED2-AE2E-C1CFAE675165%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote:

On 23 April 2024 18:41:34 BST, Matthias Koeppe  
wrote: 
>*$ git blame src/sage/combinat//designs/block_design.py* 
> 
>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 65) 
>lazy_import('sage.libs.gap.libgap', 'libgap') 
>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 66) 
>lazy_import('sage.matrix.matrix_space', 'MatrixSpace') 
>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 67) 
>lazy_import('sage.modules.free_module', 'VectorSpace') 
>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 68) 
>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>'FiniteField') 
> 
>What you see there is the result of work in the modularization project, 
>using one of the techniques documented 
>in 
https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages

>("Reducing module-level run-time dependencies:") to reduce dependencies or 
>to make dependencies milder. 

The problem is that without these imports, lazy or not, this module is 
basically useless.

That's correct, but that's not a "problem". 

It's part of a deliberate design, explained in detail in my 2023-06 
sage-devel posts. 

>From "*Modularization project: IV. The rules*" 
(https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s):
*3.* Distribution packages declare build dependencies and runtime 
dependencies 

 (on 
other Python distribution packages). These two can be entirely unrelated to 
each other. In addition to the runtime dependencies, it is possible to 
declare extra dependencies – either those necessary for running tests 

 or 
for providing advertised  

extra  

features 
.

But there is no such thing as an "optional build dependency" or 
"conditional compilation". The set of modules that form a distribution 
package is static. There is no place in the name (or metadata) of a wheel 
package that could indicate different "configurations".

*4. *As a result of 3, it is possible to create distributions that contain 
some modules that cannot be imported because some of their dependencies are 
missing. That's OK; they can become importable simply by the presence of 
other distributions, in particular those declared as extra dependencies. 
All of this is discovered at the time of importing a module; there is no 
ahead-of-time linking step of any sort.

>From "*Modularization project: V. The blocs*" 
(https://groups.google.com/g/sage-devel/c/kiB32zP3xD4):
*We should not attempt to define a distribution package for every possible 
community or subfield of mathematics that Sage supports.*
The proposed design instead introduces 3 types of distribution packages: 
[...]
Each of the distribution packages can define a list of extras (nicknames 
for sets of other distribution packages that provide additional advertised 
features). When using pip to install a distribution, users can use square 
bracket notation to add (adjoin?) these extras.

-- 
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/66e08815-08bc-439f-be60-af476b7185a7n%40googlegroups.com.

[sage-devel] Question: why does /usr/bin/gcc get called during Sage startup?

I discovered, by installing the Sage_macOS app on a pristine macOS system, 
that somehow, somewhere, in Sage's startup sequence there is a call to 
gcc.  This is true whether Sage is being started from a command line or a 
notebook.

On such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
to be posted which asks whether to download and install the Xcode "command 
line tools".

There is no need for a user to install, or be prompted to install, a C 
compiler in order to run Sage.  If we want to verify whether a C compiler 
is installed on the host system then we should check the return value of 
xcode-select 
-p rather than calling /usr/bin/gcc.

I am unable to find where this call occurs.  Do any of the Sage developers 
know which component of Sage could be calling /usr/bin/gcc on start up?

- Marc

-- 
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/a3a6a0e5-a49a-4b90-b9d0-e9515093c745n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)




On 23 April 2024 18:41:34 BST, Matthias Koeppe  wrote:
>On Tuesday, April 23, 2024 at 10:32:22 AM UTC-7 Dima Pasechnik wrote:
>
>in 
>src/sage/combinat//designs/block_design.py 
>
>you can see 
>
>lazy_import('sage.libs.gap.libgap', 'libgap') 
>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>'FiniteField')
>
>
>*$ git blame src/sage/combinat//designs/block_design.py*
>
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   65) 
>lazy_import('sage.libs.gap.libgap', 'libgap')
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   66) 
>lazy_import('sage.matrix.matrix_space', 'MatrixSpace')
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   67) 
>lazy_import('sage.modules.free_module', 'VectorSpace')
>fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   68) 
>lazy_import('sage.rings.finite_rings.finite_field_constructor', 
>'FiniteField')
>
>What you see there is the result of work in the modularization project, 
>using one of the techniques documented 
>in 
>https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages
> 
>("Reducing module-level run-time dependencies:") to reduce dependencies or 
>to make dependencies milder.


The problem is that without these imports, lazy or not, this module is 
basically useless.


>
>

-- 
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/1EA68E6E-0DC2-4D94-8C6A-39ABF3203436%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tuesday, April 23, 2024 at 10:32:22 AM UTC-7 Dima Pasechnik wrote:

in 
src/sage/combinat//designs/block_design.py 

you can see 

lazy_import('sage.libs.gap.libgap', 'libgap') 
lazy_import('sage.rings.finite_rings.finite_field_constructor', 
'FiniteField')


*$ git blame src/sage/combinat//designs/block_design.py*

fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   65) 
lazy_import('sage.libs.gap.libgap', 'libgap')
fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   66) 
lazy_import('sage.matrix.matrix_space', 'MatrixSpace')
fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   67) 
lazy_import('sage.modules.free_module', 'VectorSpace')
fdbe7f7e3348 (Matthias Koeppe2023-07-12 10:53:08 -0700   68) 
lazy_import('sage.rings.finite_rings.finite_field_constructor', 
'FiniteField')

What you see there is the result of work in the modularization project, 
using one of the techniques documented 
in 
https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages
 
("Reducing module-level run-time dependencies:") to reduce dependencies or 
to make dependencies milder.


-- 
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/d891ed13-9ecd-40d5-81d0-f196f41a3a76n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tuesday, April 23, 2024 at 8:38:13 AM UTC-7 Martin R wrote:

If I understand correctly, the current proposal does not mind if some 
things don't work or could be replaced without too much effort.  For 
example, Dima might have referred to the fact that 
OrderedPartitions.cardinality uses gap, even though it is in 
sagemath-combinat.

The gap dependency in `designs.database` (which is in sagemath-graphs) and 
`matrices.latin` (which is in sagemath-combinat) might have been overlooked.


Dependencies come in different flavors, or strengths. See again 
https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages

Here's a tl;dr version:

*Build-time dependencies:* If a Cython module uses cimport to pull in 
anything from .pxd files, these files must be either part of the portion 
shipped as the distribution being built, or the distribution that provides 
these files must be declared as a build-time dependency.

*Module-level runtime dependencies:* Any import statements at the top level 
of a Python or Cython module are executed when the module is imported. 
Hence, the imported modules must be part of the distribution, or provided 
by another distribution – which then must be declared as a run-time 
dependency.

*Other runtime dependencies:* If import statements are used within a 
method, the imported module is loaded the first time that the method is 
called. Hence the module defining the method can still be imported even if 
the module needed by the method is not present. 
It is then a question whether a run-time dependency should be declared. If 
the method needing that import provides core functionality, then probably 
yes. 
But if it only provides what can be considered “optional functionality”, 
then probably not, and in this case it will be up to the user to install 
the distribution enabling this optional functionality. It is possible to 
declare such *optional runtime dependencies* as "extras", which provides a 
way to give a nickname to a distribution that can be installed as an add-on.

*Doctest-only dependencies:* Doctests often use examples constructed using 
functionality provided by other portions of the Sage library. This kind of 
integration testing is one of the strengths of Sage; but it also creates 
extra dependencies. We can deal with them using the same mechanism that we 
use for making doctests conditional on the presence of optional libraries: 
using "# optional - FEATURE" (or "# needs FEATURE") directives in the 
doctests. Adding these directives will allow developers to test the 
distribution separately, without requiring all of Sage to be present.


Looking at your examples:

*$ head -n 4 src/sage/combinat/matrices/latin.py*
# sage_setup: distribution = sagemath-combinat
# sage.doctest: needs sage.combinat sage.groups sage.modules
r"""
Latin Squares

So here you see that the module is shipped by the distribution 
*sagemath-combinat*, but the functionality in this module depends at 
runtime on the features "sage.combinat sage.groups sage.modules".



*$ head -n 3 src/sage/combinat/designs/database.py*# sage_setup: 
distribution = sagemath-graphs
r"""
Database of small combinatorial designs
*$ git grep '# needs' src/sage/combinat/designs/database.py*
src/sage/combinat/designs/database.py:sage: 
is_difference_matrix(M,G,8,1) # 
needs sage.rings.finite_rings
src/sage/combinat/designs/database.py:sage: _ = 
designs.difference_matrix(56,8)   # 
needs sage.rings.finite_rings
src/sage/combinat/designs/database.py:sage: G,M = DM_57_8_1()   
  # needs 
sage.rings.finite_rings sage.schemes
src/sage/combinat/designs/database.py:sage: 
is_difference_matrix(M,G,8,1) # 
needs sage.rings.finite_rings sage.schemes
src/sage/combinat/designs/database.py:sage: _ = 
designs.difference_matrix(57,8)   # 
needs sage.rings.finite_rings sage.schemes
src/sage/combinat/designs/database.py:sage: _ = 
designs.difference_matrix(75,8)   # 
needs sage.rings.finite_rings
src/sage/combinat/designs/database.py:sage: G,M = DM_273_17_1() 
  # needs sage.schemes
src/sage/combinat/designs/database.py:sage: 
is_difference_matrix(M,G,17,1)# 
needs sage.schemes
src/sage/combinat/designs/database.py:sage: _ = 
designs.difference_matrix(273,17) # 
needs sage.schemes
src/sage/combinat/designs/database.py:sage: G,M = DM_993_32_1() 
  # needs sage.schemes
src/sage/combinat/designs/database.py:sage: 
is_difference_matrix(M,G,32,1)

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Monday, April 22, 2024 at 2:22:36 AM UTC-7 Martin R wrote:

I still don't see why you would name these distributions as you do, and why
you collect them as you do.

Above I explained, "I introduce these packages to create *discoverability* for
potential consumers of portions of the Sage library. (pip-installable
packages are often named after the functionality that they provide.)"

For example, as far as I know, symmetrica is currently essentially only
used by symmetric functions, Schubert polynomials. So, if symmetrica is
such a burden to install, why would you want to install it if you don't
need them?

*symmetrica*, as a single dependency on its own, is not "such a burden to
install".
Dependencies can become a burden simply if there are too many of them.

I have defined the distributions with an eye on keeping the number of
distributions and the complexity low.

But there's no dogma. If the community finds it useful, then a distribution
**sagemath-symmetrica* could later be split out from *sagemath-combinat*
and can become either a required dependency or an optional dependency of
*sagemath-combinat*.

On the other hand, combinatorial species will, after this summer, heavily
depend on gap. Does this mean that you would want to move this part into
sage-groups?

If it has a build-time dependency on sage.libs.gap, then it would likely be
shipped by *sagemath-gap*. If it's merely a runtime dependency, it does not
really matter from a technical point of view which distribution ships it.
(Once more I refer to the chapter in the Developer Guide that explains the
different types of dependencies,
https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages)

It could then be advertised, for example, as an "extra" of
*sagemath-combinat* so that it can be installed as "pip install '
*sagemath-combinat*[species]'" or "pip install '*sagemath-combinat*[gap]'",
like
the existing definitions of extras that make it possible to do "pip install
'*sagemath-combinat*[modules]'" for typical algebraic combinatorics
features.
https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L40

I gave more examples for the use of such extras in my 2023-06 sage-devel
post "Modularization project: V. The blocs",
https://groups.google.com/g/sage-devel/c/kiB32zP3xD4

Apart from the strange naming, I don't think that it will make anybody
happy if dependencies change frequently.

Hard to tell what exactly you find strange about the naming if you're not
more specific.

In https://github.com/sagemath/sage/pull/36964#discussion_r1564162445 and
below, you already expressed surprise that trees and posets are in
*sagemath-graphs* and that symmetric functions are in *sagemath-combinat*.

I'll just say that the existing design is the result of years of work that
has taken all of the following into account:
- the technical constraints of Python packaging,
- the actual dependencies of the Sage library,
- discoverability by users,
- attribution and visibility for upstream libraries/projects,
- the overall complexity,
- and the potential for connecting the new distributions to communities of
users and developers.

But as I said above, there's no dogma as to what exactly goes into what
distribution, and the Sage developer community will be able to change it
over time, like everything in Sage.

--
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/46b37837-f0ea-4e65-aee1-9864007ea164n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tue, Apr 23, 2024 at 3:31 PM Matthias Koeppe
 wrote:
>
> On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote:
>
> On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe  wrote:
>
> Let's just go through the list of distribution packages and their 
> dependencies for concreteness. (All depend on sagemath-categories and thus on 
> the basic arithmetic libraries gmp, mpc, mpfr, gmpy2)
>
>
> these are seemingly incomplete:
>
>
> What makes that seem to you?
>
>
> sagemath-combinat
> - non-Python dependency: symmetrica 
> (https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L65)
>
> non-python: depends on GAP, givaro, too
>
>
> No. Your source?
in

src/sage/combinat//designs/block_design.py

you can see

lazy_import('sage.libs.gap.libgap', 'libgap')
lazy_import('sage.rings.finite_rings.finite_field_constructor', 'FiniteField')


>
>
>
>
> sagemath-graphs
> - non-Python dependency: boost 
> (https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-graphs/pyproject.toml.m4#L73)
>
>
> non-python:  depends on GAP, givaro, too
>
>
> No. Source?

similar to the above

>
>
> sagemath-modules
> - non-Python dependency: gsl 
> (https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-modules/pyproject.toml.m4#L109)
> - Python build requirement: numpy
>
>
> non-python: linbox, flas_ffpac, too ?
>
>
> No. Source?

same as above, basically

These modules don't function in any meaningful way without
dependencies I listed.

Dima
>
> --
> 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/f54a1d55-b7c2-47a8-9245-d470a63091fan%40googlegroups.com.

-- 
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/CAAWYfq2AzRpc-fvxSki%3Dg8P%3D%2B%3DExWqidb%3Dtcm7DrzLmY2W89Qw%40mail.gmail.com.

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tuesday, April 23, 2024 at 5:35:10 AM UTC-7 Kwankyu Lee wrote:

I meant the sage library as a collection of mathematical modules. If a 
certain module did not but somehow would develop to rely on the 
mathematical functionality of another module, then the design of the 
modularization should embrace the development. The splitting of the sage 
library  in the present modularization reflects the present reality of the 
separation of different mathematical parts of the sage library. But of 
course the reality may change in the future as we develop the sage library. 
Then the modularization should reflect the change, not block the change.


Exactly. The design of the modularized distributions can evolve, and like 
everything in Sage, such changes will be in the hands of the Sage developer 
community.

-- 
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/73f94b7b-a5ec-458d-973c-49c29b0b9f2bn%40googlegroups.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

2024-04-23 Thread seb....@gmail.com

> *Just go with how github works, which is positive review = ready to merge 
and "files changed" shows the actual changes that this PR implements.*

The problem with this is: if there are commits on a branch that are 
reviewed in more than one PR, the question is: does *positive review* mean 
*all* or *some* PR's? I don't think *some* is a good choice. Unfortunately, 
I don't have the time to read through all these controversial PR's at the 
moment. However, what I have seen is that every dispute started with one 
participant feeling ignored by others. Maybe this is enforced by written 
communication. But, if we allow a procedure that systematically ignores the 
opinions of some reviewers, we may be adding fuel to the fire.

Therefore I would have voted +1 if I hadn't missed the deadline. Like 
Travis, my vote is independent of the content of #36964.

Volker Braun schrieb am Samstag, 20. April 2024 um 11:04:24 UTC+2:

> It was merged because it was positively reviewed. 
>
> Neither I nor the merge script reads every ticket description and looks 
> through the text whether any dependency is mentioned that has not yet been 
> reviewed. We can try to build such a Rube Goldberg machine, but I would 
> very much argue against it. Just go with how github works, which is 
> positive review = ready to merge and "files changed" shows the actual 
> changes that this PR implements. Anything else will just prevent us from 
> using standard tooling in the future. If anything introduce a "preliminary 
> positive review" tag that gets replaced with actual positive review when 
> the dependencies are in.
>
> On Friday, April 19, 2024 at 9:50:35 AM UTC+2 Travis Scrimshaw wrote:
>
>> +1 for merging #37796.
>>
>> Volker, I would appreciate if you could say something about how #36964 
>> was merged. It would be useful to understand the process with merging this, 
>> rather than guessing the intent. Additionally, I thought we didn't merge 
>> things when the dependencies have not been merged (or merged 
>> simultaneously)? (This is why I am voting for reverting.)
>>
>> Best,
>> Travis
>>
>> On Friday, April 19, 2024 at 9:57:25 AM UTC+9 G. M.-S. wrote:
>>
>>>
>>> -1
>>>
>>> If something has been done that should be undone, I very much trust 
>>> Volker to take care of it when he can, without the need for endless 
>>> time-consuming discussions and votes.
>>>
>>> Best,
>>>
>>> Guillermo
>>>
>>> On Thu, 18 Apr 2024 at 17:54, David Roe  wrote:
>>>
 Hi all,
 Sage has had a review process for over 15 years, but a combination of 
 recent changes has led to the merging of a PR into sage-10.4.beta3 of a 
 change (#36964 ) that I 
 believe should not (yet) have been merged.  In #37796 
  I created a PR to revert 
 the change, which was opposed by the author of the original change.  After 
 some 
 voting 

 using the disputed PR policy 
 , 
 Matthias has asked 

 for a vote on sage-devel about this reversion, in accordance with the 
 section that "This process is intended as a lower-intensity method for 
 resolving disagreements, and full votes on sage-devel override the process 
 described below."  I am therefore asking you to vote (+1 means merge 
 #37796  in order to 
 revert #36964 ).

 First, here are the relevant parts of the history of this particular 
 change:

 - #36964  was created on 
 December 25 by Matthias, positively reviewed 

 by Kwankyu on Decemebr 27, disputed, received enough votes 

 to get a positive review on April 7, and was merged 

 by Volker on April 12.  It had dependencies: #37667, 
 #36951 
 , and #36676 
 .  While #37667 
  had positive review and 
 was already been merged, the other two were still disputed: they had 
 received an initial positive review but others objected and discussion was 
 ongoing.

 - #37667  is not disputed.

 - #36951  was created on 
 December 23 by Matthias, positively reviewed

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

2024-04-23 Thread 'Martin R' via sage-devel

If I understand correctly, the current proposal does not mind if some 
things don't work or could be replaced without too much effort.  For 
example, Dima might have referred to the fact that 
OrderedPartitions.cardinality uses gap, even though it is in 
sagemath-combinat.

The gap dependency in `designs.database` (which is in sagemath-graphs) and 
`matrices.latin` (which is in sagemath-combinat) might have been overlooked.

Martin

On Tuesday 23 April 2024 at 16:31:36 UTC+2 Matthias Koeppe wrote:

> On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote:
>
> On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe  
> wrote:
>
> Let's just go through the list of distribution packages and their 
> dependencies for concreteness. (All depend on *sagemath-categories* and 
> thus on the basic arithmetic libraries gmp, mpc, mpfr, gmpy2)
>
>
> these are seemingly incomplete:
>
>
> What makes that seem to you?
>  
>
> *sagemath-combinat* 
> - non-Python dependency: *symmetrica* (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L65
> )
>
> non-python: depends on GAP, givaro, too
>
>
> No. Your source?
>  
>
>  
>
> *sagemath-graphs*
> - non-Python dependency: *boost *(
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-graphs/pyproject.toml.m4#L73
> )
>
>
> non-python:  depends on GAP, givaro, too
>
>
> No. Source?
>  
>
> *sagemath-modules*
> - non-Python dependency: *gsl* (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-modules/pyproject.toml.m4#L109
> )
> - Python build requirement: 
> *numpy*
>
>
> non-python: linbox, flas_ffpac, too ?
>
>
> No. Source?
>
>

-- 
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/cddf6e13-9bdd-40a0-9e20-fe8d9be0a233n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote:

On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe  
wrote:

Let's just go through the list of distribution packages and their 
dependencies for concreteness. (All depend on *sagemath-categories* and 
thus on the basic arithmetic libraries gmp, mpc, mpfr, gmpy2)


these are seemingly incomplete:


What makes that seem to you?
 

*sagemath-combinat* 
- non-Python dependency: *symmetrica* (
https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L65
)

non-python: depends on GAP, givaro, too


No. Your source?
 

 

*sagemath-graphs*
- non-Python dependency: *boost *(
https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-graphs/pyproject.toml.m4#L73
)


non-python:  depends on GAP, givaro, too


No. Source?
 

*sagemath-modules*
- non-Python dependency: *gsl* (
https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-modules/pyproject.toml.m4#L109
)
- Python build requirement: 
*numpy*


non-python: linbox, flas_ffpac, too ?


No. Source?

-- 
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/f54a1d55-b7c2-47a8-9245-d470a63091fan%40googlegroups.com.

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Tuesday, April 23, 2024 at 4:07:37 AM UTC-5 Tobias wrote:

In reply to the comment (
https://github.com/sagemath/sage/pull/36676#issuecomment-2067371677)

once the modularization is in place, it will impose wide-ranging
constraints on what functions from other modules you are able to use.
Currently, you can use `sage.x` in `sage.y` for an arbitrary combination of
`x` and `y`. The modularization project restricts this severely and you
will only be able to use modules `x` that are declared as a dependency of
`y` (the arrows in the picture in
https://github.com/sagemath/sage/pull/35095).

This comment seems to me to reflect a basic misunderstanding of the goal of
modularization. The author is assuming that Sage users will have to make
choices about which parts of Sage to install and find many things missing.
But Sage users should, as they do now, install all of Sage -- everything
should be available to a user who does a normal install of Sage. The
projects that will really benefit from modularization will be those that
provide their own limited mathematical context. Developers of such
projects will be able to choose which parts of Sage are relevant to their
specific context. Those parts of Sage can be provided for their users
without having to embed a huge monolithic environment into a relatively
small project. For example, people studying 3-manifolds mainly need to
work with simplicial complexes, groups, polynomials, number fields and
interval arithmetic. They do not need many other large parts of Sage, such
as abstract manifolds (since all 3-manifolds can be triangulated).

This is basically a tautological argument, saying that modularization will
cause modularization. It does not reflect the reality for *users*.

- Marc

--
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/085048b3-a1f4-45db-8513-12516794d24an%40googlegroups.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

2024-04-23 Thread David Roe

The vote was 8-4.  I'm setting the PR back to positive review.
David

On Sat, Apr 20, 2024 at 5:04 AM Volker Braun  wrote:

> It was merged because it was positively reviewed.
>
> Neither I nor the merge script reads every ticket description and looks
> through the text whether any dependency is mentioned that has not yet been
> reviewed. We can try to build such a Rube Goldberg machine, but I would
> very much argue against it. Just go with how github works, which is
> positive review = ready to merge and "files changed" shows the actual
> changes that this PR implements. Anything else will just prevent us from
> using standard tooling in the future. If anything introduce a "preliminary
> positive review" tag that gets replaced with actual positive review when
> the dependencies are in.
>
> On Friday, April 19, 2024 at 9:50:35 AM UTC+2 Travis Scrimshaw wrote:
>
>> +1 for merging #37796.
>>
>> Volker, I would appreciate if you could say something about how #36964
>> was merged. It would be useful to understand the process with merging this,
>> rather than guessing the intent. Additionally, I thought we didn't merge
>> things when the dependencies have not been merged (or merged
>> simultaneously)? (This is why I am voting for reverting.)
>>
>> Best,
>> Travis
>>
>> On Friday, April 19, 2024 at 9:57:25 AM UTC+9 G. M.-S. wrote:
>>
>>>
>>> -1
>>>
>>> If something has been done that should be undone, I very much trust
>>> Volker to take care of it when he can, without the need for endless
>>> time-consuming discussions and votes.
>>>
>>> Best,
>>>
>>> Guillermo
>>>
>>> On Thu, 18 Apr 2024 at 17:54, David Roe  wrote:
>>>
 Hi all,
 Sage has had a review process for over 15 years, but a combination of
 recent changes has led to the merging of a PR into sage-10.4.beta3 of a
 change (#36964 ) that I
 believe should not (yet) have been merged.  In #37796
  I created a PR to revert
 the change, which was opposed by the author of the original change.  After 
 some
 voting

 using the disputed PR policy
 ,
 Matthias has asked

 for a vote on sage-devel about this reversion, in accordance with the
 section that "This process is intended as a lower-intensity method for
 resolving disagreements, and full votes on sage-devel override the process
 described below."  I am therefore asking you to vote (+1 means merge
 #37796  in order to
 revert #36964 ).

 First, here are the relevant parts of the history of this particular
 change:

 - #36964  was created on
 December 25 by Matthias, positively reviewed

 by Kwankyu on Decemebr 27, disputed, received enough votes

 to get a positive review on April 7, and was merged

 by Volker on April 12.  It had dependencies: #37667,
 #36951
 , and #36676
 .  While #37667
  had positive review and
 was already been merged, the other two were still disputed: they had
 received an initial positive review but others objected and discussion was
 ongoing.

 - #37667  is not disputed.

 - #36951  was created on
 December 23 by Matthias, positively reviewed

 by Kwankyu on January 1, disputed, received enough votes

 (3-1) to change to positive review on April 7, had a clarification to bring
 back to (3-2) and remove positive review, then was included in the merge of
 #36964 . On April 13,
 John Palmieri voted in favor
 ,
 so the current vote stands at 4-2, enough for the 2-1 threshold in order to
 get positive review under the disputed voting process.

 - #36676  was created on
 November 8 by Matthias, positively reviewed

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)