Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On 10 June 2024 17:27:55 BST, Matthias Koeppe  wrote:
>On Monday, June 10, 2024 at 7:52:09 AM UTC-7 Kwankyu Lee wrote:
>
>This is Dima's response:
>> [...] multi-Gigabyte  territory.
>
>
>For a fact-based discussion, people may want to look at the actual size of 
>the wheels of the only rust-based package that we are discussing. 
>https://pypi.org/project/rpds-py/#files (look for files *-cp*-.whl)
>It's just a few megabytes total.
rpds-py is rather small.

We are discussing your (general) proposal to provide binary wheels for packages 
by mirroring PyPI.
That is where gigabytes come from.
E.g. the binary wheels for scipy (with one version of Python) add up to about 
200Mb.

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/9FB76EAA-8368-4B08-9CC9-335134AE7F56%40gmail.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On 10 June 2024 17:21:16 BST, Matthias Koeppe  wrote:
>On Monday, June 10, 2024 at 7:37:48 AM UTC-7 Kwankyu Lee wrote:
>
>So, why do we need to mirror PyPI ?  
>
>
>I understand "mirroring PyPI"  as what we do with "wheel" packages, that 
>is, delivering the wheel (downloaded from PyPI) of the specified version in 
>the sage tarball.
>
>
>Exactly.

Exactly, what?

 I explained to Kwankyu that I mean "mirroring" in the usual sense of this 
word, not the one he thought.

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/DC52175F-7A77-490E-915A-33163B52BE42%40gmail.com.

Re: [sage-devel] Re: Demote brial (= polybori) from standard to experimental

[Dima Pasechnik]

+1

On 10 June 2024 17:41:07 BST, Nathan Dunfield  wrote:
>This makes sense to me.
>
>Nathan
>
>On Sunday, October 1, 2023 at 2:29:55 PM UTC-5 Matthias Koeppe wrote:
>
>I propose to demote this package to experimental.
>- It has been declared dead at least once -  
>https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/
>- It has no upstream maintainer (except for ermergency fixes by Francois 
>Bissey) - https://github.com/BRiAl/BRiAl/graphs/contributors, 
>https://sourceforge.net/projects/polybori/
>- It has been dropped from Debian testing, where it seems to block SageMath 
>upgrades (Sage is stuck at 9.5 in Debian/Ubuntu)
>- The conda and homebrew packages of brial lead to segfaults (
>https://github.com/sagemath/sage/issues/35595, 
>https://github.com/sagemath/sage/issues/34780)
>- It is disconnected from the advances in SMT (satisfiability modulo 
>theories) over the past decade (representative paper: 
>https://arxiv.org/abs/2305.00028v2)
>
>
>

-- 
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/62B6B142-961F-43D9-9BDD-92A0AE75691F%40gmail.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Mon, Jun 10, 2024 at 3:52 PM Kwankyu Lee  wrote:
>
> This is Dima's response:
>
> > None are relevant:
> > (1) can be trivially achieved without mirroring.
> > (2) is irrelevant here, as creating a tarball with all these binary
> > wheels pushes us into multi-Gigabyte  territory.
> > That is, you'd need prefetch the set of binary wheels for your machine
> > somehow - and again, for this you don't need to mirror PyPI.
>
> In my own words, he seems to be saying that "we don't need to download the 
> wheel and put it into our tarball; we can just call pip to fetch the 
> specified version from internet at install time". To do what he is 
> advocating, all we have to do is to throw away the "no internet for 
> installing from tarball" assumption.
>
> Did I understand you correctly, Dima?

Yes and no: namely, using the proposed mirrored binary wheels will throw away
"no internet for installing from tarball" assumption. just as well.
So there is no difference at this point.

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/f5ff66fd-6164-496b-9b4b-39663ce23eb5n%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/CAAWYfq3M-cMYyPOOQ3qaf3cDOvxA1rA7xcsDY6q21--0sFyHPw%40mail.gmail.com.

[sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Monday, June 10, 2024 at 3:37:48 PM UTC+1 Kwankyu Lee wrote:

So, why do we need to mirror PyPI ?  


I understand "mirroring PyPI"  as what we do with "wheel" packages, that 
is, delivering the wheel (downloaded from PyPI) of the specified version in 
the sage tarball.


This is not mirroring. Mirroring is setting up a site B which in part 
copies content from another site A. Then one says "B is mirroring A".
See examples in upstream/mirror_list.

With binary wheels, creating a reasonable size tarball containing what's 
needed to install Sage on a particular platform easily gets into Gigabytes.
It's also not clear whether the existing mirror structure would allow for 
much more content and traffic - but that's another story.

-- 
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/2a009466-cf84-4f21-9cf8-123cd41cace7n%40googlegroups.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Mon, Jun 10, 2024 at 2:18 PM Kwankyu Lee  wrote:
>
> To add  variation to this boring discussion, let me intervene:
>
>
> So, why do we need to mirror PyPI ?
>
>
> From this discussion, I guess that the answer is
>
> 1. We want to pin the version of standard package
> 2. We do not want to assume internet connection
>
> Is there other reason, Matthias?
>
> Dima, which of (1) and (2) do you think we can abolish?
>
None are relevant:

(1) can be trivially achieved without mirroring.

(2) is irrelevant here, as creating a tarball with all these binary
wheels pushes us into multi-Gigabyte  territory.
That is, you'd need prefetch the set of binary wheels for your machine
somehow - and again, for this you don't need to mirror PyPI.

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/b47a3e26-31e6-4755-8a7d-20e6e471aa9en%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/CAAWYfq32ymR_Kz6zp3wEzRkrszg%2B8Yr6u7i%3DaAsOFTsVaFKfZA%40mail.gmail.com.

[sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Monday, June 10, 2024 at 1:53:59 AM UTC+1 Matthias Koeppe wrote:

On Sunday, June 9, 2024 at 5:25:54 PM UTC-7 Dima Pasechnik wrote:

Is there any Python project which resorts to mirroring binary PyPI wheels?


Sage-the-Python-project does not do this.

Sage-the-distribution does. Distributions do distribution stuff. 

More questions?


You've pulled this line ("Is there any Python project which resorts to 
mirroring binary PyPI wheels?") out of context.
Let me re-iterate.

> And what is the point of this? Why do we need to mirror PyPI?
> Is there any Python project which resorts to mirroring binary PyPI wheels?

So, why do we need to mirror PyPI ? The only "distro" that does it is Sage 
itself, AFAIK.
What are the reasons to believe that it will improve anything? The burden 
of such a move
is quite considerable, on the other hand.

> I think it's a very drastic step, and it needs to be discussed, brought 
up for a vote, etc.

So you don't think this needs any further discussion?

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/263a84f5-28bc-4821-a248-9e7589821559n%40googlegroups.com.

Re: [sage-devel] Error building package python3-3.11.8

[Dima Pasechnik]

Why do you even need to build Python 3.11? Don't you have system-wide
3.12 which you can use?
It would help if you post full toplevel config.log.

It would also be good to put Sage to a directory which doesn't have
non-ASCII characters in the full path, and no spaces in it - it seems
it's not the case:

[spkg-build] Header file
/home/francois/T\�\�l\�\�chargements/sage-10.4.beta8/local/lib/libffi-3.2.1/include/ffi.h


On Mon, Jun 10, 2024 at 1:22 AM Laurent anaguet
 wrote:
>
> Hi!
> I tried to install sagemath-10.4-beta8 on xubuntu24.04 but it didn't work. I 
> have a message:
>  Error building package python3-3.11.8. What does it wrong? The file log is 
> in attchment.
> thanks!
>
>
> --
> 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/2d81071f-2c78-4a0e-8b97-db4f2baa18c3n%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/CAAWYfq1HJr%2BfxahX4j578BY81G%2B5hotMnysmQ8VpdFd50aGgvQ%40mail.gmail.com.

[sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Wednesday, June 5, 2024 at 8:00:54 PM UTC+1 Matthias Koeppe wrote:

On Wednesday, June 5, 2024 at 9:46:05 AM UTC-7 Dima Pasechnik wrote:

On Monday, June 3, 2024 at 8:16:30 PM UTC+1 Matthias Koeppe wrote:

Unlikely that we would add a package to the Sage distribution that builds a 
Rust library from source. 

Not so long ago we added support for installing Python packages from 
platform-independent wheels. We did this to sidestep the concern of 
shipping more and more of Javascript (Node.js) infrastructure that is 
needed for building JupyterLab components.

Likewise, we will soon add support for installing Python packages from 
platform-dependent wheels. This is needed for updating some Jupyter 
components that have started to use Rust (https://github.com/crate-py/rpds, 
a dependency of jsonschema).


Could you be more specific on this, please? [...] Where would these wheels 
come from? From PyPI?



(In the Sage distribution, they won't be "pip" packages -- which are an 
underdeveloped mechanism in the build system of the Sage distribution -- 
but rather a variant of the existing "wheel" packages.)

As the upstream developer, you would publish binary wheels to PyPI, likely 
in the same way as is done in 
https://github.com/crate-py/rpds/blob/main/.github/workflows/CI.yml


- Like I wrote below the fold: The upstream project makes the binary wheels 
and uploads them to PyPI as usual.
- When we make a package update in the Sage distribution, we download the 
wheels from PyPI (the upstream_url of the package) and upload them to the 
mirrors (and to the GitHub Release Assets).
- When the package is installed, the Sage distribution downloads the wheels 
from GitHub Release Assets, falling back to mirrors, then falling back to 
the upstream_url.

In other words, just like what we do for any other normal/wheel package in 
the Sage distribution. 

The only technical change: There's more than one "tarball" associated with 
these packages.


And what is the point of this? Why do we need to mirror PyPI?
Is there any Python project which resorts to mirroring binary PyPI wheels?
I think it's a very drastic step, and it needs to be discussed, brought up 
for a vote, etc.

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/1c2681d8-7c7e-4b48-be8d-0e504a2cae13n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

On 6 June 2024 18:06:53 BST, Matthias Koeppe  wrote:
>On Thursday, June 6, 2024 at 3:56:15 AM UTC-7 Dima Pasechnik wrote:
>
>What's described here is a very well known fact: "pip install" (or "sage 
>--pip install") might mess up your venv, anyone who works with large 
>collections of python packages is well aware of it.
>
>
>That's right. 
>People are aware of it when they use pip _manually_.
>And when something goes wrong, people tend to delete their venvs and start 
>over.
>
>Talking about it as something "underdeveloped in Sage" is a bit strange, 
>these are just well-known features and deficiencies of pip.
>
>
>You are missing the point: We cannot build something that is expected to be 
>robust on top of this automated use of "pip", to install and update 
>packages one by one, in the Sage distribution. 

Why? E.g. scipy/numpy and sympy do not hoard compilers, do not ship a vendored 
Jupyter, or pytest, or Sphinx, or matplotlib, or OpenBLAS - yet are  popular 
and successful - and thus robust, I presume.
It seems that you are missing the point of how to build a successful project, 
by demanding that we don't follow the normal Python practices, as these are 
"not robust".

>
>Yet, pytest, a pip package, is installed and used rather regularly in Sage, 
>and nobody gets hurt. It is found to be safe to install this particular 
>package this way ("pip install pytest" does not affect anything in the Sage 
>venv, that's why).
>
>
>That so far there has not been breakage (other than that our use of pytest 
>itself was entirely broken) just means that we have been lucky.

No, this means that pytest folks do a good job, and we use results of their 
hard work wisely, without vendoring and version micromanagement.

>There is simply no mechanism that is keeping it safe, even retroactively (= 
>for the same published version of Sage).
>Even pinning the pytest version would not be enough because any of its 
>_dependencies_ (unpinned, and undeclared in the Sage distribution), when a 
>future version of that is published to PyPI, can add an incompatible 
>dependency itself. 
>By converting packages to "pip" packages, these interdependencies -- 
>exactly through the random packages that nobody wants to know or care about 
>-- are hidden complexity, which only becomes visible when something breaks.

"something breaks" for you means "stops installing".
But it can well be broken underneath, even though it installs. E.g. we are 
shipping rather broken symbolic routines - sure, they install, but they often 
produce incorrect results, and leak memory. Also, our graphics routines have a 
huge room for improvement. Etc.


>
>There is no reason not to promote it to standard and keep it a pip package.
>
>(Same applies to any other well-isolated from the rest of Sage bunch of 
>packages, e.g. Sphinx+Jupyter, i.e. the vast majority of Python packages
>
>
>No, that's just wishful thinking. There's absolutely no mechanism that 
>isolates them. 
>Common dependencies can become incompatible, and then by the action of the 
>resolver, things will break.


No, it's mostly because you want to micromanage each and every PyPI package 
involved in Sage. But we don't need this, if instead we use a few well tested 
largish components - because their providers actually test things, not only in 
isolation.
Surely the latest Jupyter and Sphinx and pytest and matplotlib all work 
together rather well, almost all the time. And one can take a snapshot of 
versions and keep it if something (unlikely) breaks in an update.

>
>The extra tax we pay by not using pip
>
>packages more has started to outweight  the benefits long ago. People 
>
>don't want to spend extra time and other resources
>to maintain and build often somewhat outdated versions of packages which 
>are available from PyPI in a ready way.
>
>
>Not sure which "people" you are attempting to speak for here, and on what 
>basis. 

On the basis of previous discussions on this topic.
I don't understand why you assume that the majority of the developers wants to 
follow you and build a mini-clone of something like Conda.

>But most of the packages that you are talking about are "wheel" packages. 
>They are not "built", they are only installed. 
>And that packages may be "outdated" is outweighed by actually having 
>already been tested in this combination, so that users can actually be 
>users and not perpetual beta-testers.
>
>Pinning versions works, as everyone knows.
>
>The precaution of not using "pip install" in the Sage venv is akin to the 
>same precaution done by most, if not all, Linux distros, which just forbid 
>installing packages 

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

On 6 June 2024 18:47:43 BST, Matthias Koeppe  wrote:
>On Thursday, June 6, 2024 at 8:40:28 AM UTC-7 Dima Pasechnik wrote:
>
>the incident with pytest 8 was very mild.
>
>
>These days, describing something as "very mild" could just mean that it is 
>not regularly leading to fatal hardware damage.
>
>The "incident" was that our use of pytest was completely broken. The 
>failure also caused the CI Build to fail for months (see 
>https://github.com/sagemath/sage/pull/37999). 


It's a good question why nobody added a version pin -  which would have fixed 
it instantly.
But it's a question about our development practices, not about validity of the 
standard pip package approach.


>But yes, pytest is currently optional, and it is only required for testing 
>a very small set of modules in the Sage library. 
>So it is easy to ignore for developers, just like when other optional 
>packages break. 
>
>The proposal is to make it standard, though, and for that the robust 
>machinery of our normal/wheel packages is needed.
>

-- 
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/B0D6E92D-CDA3-4067-ACEB-2F83F8A86B54%40gmail.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

On Thu, Jun 6, 2024 at 3:05 PM Nathan Dunfield  wrote:
>
>
>
> On Thursday, June 6, 2024 at 5:56:15 AM UTC-5 Dima Pasechnik wrote:
>
> Yet, pytest, a pip package, is installed and used rather regularly in Sage, 
> and nobody gets hurt. It is found to be safe to install this particular 
> package this way ("pip install pytest" does not affect anything in the Sage 
> venv, that's why).
>
>
> Yet because the version of pytest wasn't pinned, things broke when pytest 8.* 
> came out.  This would not have happened if pytest had been installed as a 
> wheel package.  (As you say, pip packages can also be pinned to a particular 
> version, though for a pure-Python package the only difference between wheel 
> and a pinned pip is whether dependencies also have to be included.)

I never said that we must never pin versions of such packages.
OTOH Sage gets broken on macOS, mostly due to XCode updates, very often,
yet one does not demand pinning of macOS versions and XCode versions.
Compared to these, the incident with pytest 8 was very mild.

>
> Dima, under your proposal that "standard packages can be pip packages", what 
> criteria would be used to decide whether (and how narrowly) to pin a 
> particular pip package?  Also, what criteria would be used to determine 
> whether (and which) dependencies would be explicitly made Sage packages?

One can look at package dependencies and see what can and what cannot
be untangled from each other, and see.
Anyhow, I just want a possibility for standard pip packages (and
pytest fits the ticket).
If you were unwilling to grant such a possibility I would not want
spend time coming up with details.

Dima
>
> Personally, I support allowing Sage to use upstream binary wheels from PyPI 
> rather than building from things source, but feel it is a mistake not to pin 
> everything and explicitly list all dependencies, at least at first.
>
> 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/fa7c82aa-ce78-471d-b5e2-35ff3a682b27n%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/CAAWYfq00h4L%2BktjSy2rrwquTPWvuBVmmkuWsOhbwvbO1BOARAg%40mail.gmail.com.

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

What's described here is a very well known fact: "pip install" (or "sage 
--pip install") might mess up your venv, anyone who works with large 
collections of python packages is well aware of it. Talking about it as 
something "underdeveloped in Sage" is a bit strange, these are just 
well-known features and deficiencies of pip.

Yet, pytest, a pip package, is installed and used rather regularly in Sage, 
and nobody gets hurt. It is found to be safe to install this particular 
package this way ("pip install pytest" does not affect anything in the Sage 
venv, that's why).

There is no reason not to promote it to standard and keep it a pip package.
(Same applies to any other well-isolated from the rest of Sage bunch of 
packages, e.g. Sphinx+Jupyter, i.e. the vast majority of Python packages - 
but that's another story, let's not discuss it here now).

>  It's really very surprising to me why anyone would be championing using 
these kinds of package types more. 

We have had these discussions already,  why it still comes as "surprising" 
to you is unclear. The extra tax we pay by not using pip
packages more has started to outweight  the benefits long ago. People don't 
want to spend extra time and other resources
to maintain and build often somewhat outdated versions of packages which 
are available from PyPI in a ready way.

--

By the way, we certainly experimented a lot with combining exclusively 
pip-installed packages with sagelib package built with Meson, and, 
surprise, it worked.
The precaution of not using "pip install" in the Sage venv is akin to the 
same precaution done by most, if not all, Linux distros, which just forbid 
installing packages with pip into the main python environment. (one needs a 
venv to use pip install).
Sage is a white crow among other python packages, in its way how it demands 
hundreds of particular versions
of extra python packages to come along. The white crows are evolutionary 
disadvantaged, and this applies to the Python universe
just as well as to the biosphere. 

Dima


On Thursday, June 6, 2024 at 3:48:10 AM UTC+1 Matthias Koeppe wrote:

> On Friday, May 31, 2024 at 9:38:34 AM UTC-7 Dima Pasechnik wrote:
>
> Before looking at 
> https://groups.google.com/g/sage-devel/c/lPLoA7zaoyg/m/dGE1B1jQEQAJ
> we should look at this proposal again, as pytest is a very suitable 
> candidate for the kinds of packages (standard pip packages)
> proposed here
>
>
> David requested over there that I explain a bit more about pip packages, 
> so here goes.
>
> The "pip" package type was added to the Sage build system in 2015 by 
> Jeroen as a quick and dirty way to keep packages such as "biopython", 
> previously available as an "old-style SPKG", available for installing after 
> switching to the "git layout" and phasing out "old-style SPKGs". We have 
> kept this mechanism around for exactly such use cases: To advertise 
> packages for which there is no real interest among developers in packaging 
> them (and updating them) properly. 
>
> And the "pip" package type has not seen any development since 2015. In 
> particular, it has not been updated in any way to account for the use of 
> build isolation that has become the default in the Python world around 
> 2020. For example, say a "pip" package has a build dependency on numpy -- 
> then during the build phase it's not even going to use our installed numpy 
> package but rather it's going to use a random binary wheel from PyPI. And 
> all of that is resolved against the index server too, so there will be 
> retroactive breakage.
>
> Moreover, when a "pip" package is installed the first time, the Sage 
> distribution really just calls "pip install ..."; this contacts the index 
> server (PyPI). And the Sage build system does not keep or check 
> installation records for these packages, so it just calls "pip install ..." 
> again *every time* that its installation is requested directly or 
> indirectly as a dependency. And "pip install" will happily do anything that 
> is requested, such as replacing any currently installed Python packages, 
> including packages installed by the Sage distribution. Nothing is pinned, 
> everything is up for grabs, and what is finally installed will also depend 
> on the order of operations.
>
> It's really very surprising to me why anyone would be championing using 
> these kinds of package types more. 
>
> Well, it does sound all very nice and simple, but unfortunately in reality 
> it's not. My suggestion to those who are actually interested in discussing 
> the build system of the Sage distribution: Learn how the Sage distribution 
> builds its Python packages, a

Re: [sage-devel] VOTE: Follow NEP 29: Recommended Python version

[Dima Pasechnik]

Actually, it doesn't seem that the votes have ever been counted here.

In view of SymPy willing to follow NEP 29 (cf. 
https://groups.google.com/g/sage-devel/c/0BPkiiWYrIU/m/c1vlJoMGEwAJ), it 
seems natural to join this trend and follow NEP 29.

On Tuesday, May 30, 2023 at 10:35:21 AM UTC+1 G. M.-S. wrote:

>
> My vote is empty, for the following reasons:
> —I think the question asked is not clear enough, as per reactions.
> —My "dream" is having an easy to install recent version of SageMath for 
> everybody wishing to do mathematics with it.  Currently this is only the 
> case for macOS and perhaps some flavours of Linux, AFAICT (my experience 
> with my students and colleagues is not very good, especially under Windows).
>
> Guillermo
>
> On Fri, 26 May 2023 at 12:12, Tobias Diez  wrote:
>
>> Dear Sage developers,
>>
>> the NumPy enhancement proposal 29: "Recommend Python and Numpy version 
>> support as a community policy standard" (available at 
>> https://numpy.org/neps/nep-0029-deprecation_policy.html) specifies when 
>> it's okay to drop support for old Python version. 
>>
>> Namely, a release should support "all minor versions of Python released 
>> 42 months prior to the project, and at minimum the two latest minor 
>> versions. ". In particular, this means:
>> - Currently, Sage should support > 3.8.
>> - On Apr 05, 2024 we should drop support for Python 3.9 (initially 
>> released on Oct 05, 2020)
>>
>> Based on previous discussions on this topic (
>> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ, 
>> https://github.com/sagemath/sage/issues/30384, 
>> https://github.com/sagemath/sage/pull/35403), I'm calling for a vote on 
>> adapting the Python version support of NEP 29 in Sage. Voting ends at the 
>> 7th June,  AoE. Please use this thread only for sending votes, to make it 
>> easier to count them afterward; and use the thread 
>> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ for 
>> discussion.
>>
>> *Summary *of the points brought forward in the discussions linked above
>> 1. The current practice in Sage is to evaluate whether to increase the 
>> minimum version of Python supported at the beginning of each release cycle. 
>> With regard to such a practice, the NEP 29 documents remarks "As there is 
>> no objective threshold to when the minimum version should be dropped, it is 
>> easy for these version support discussions to devolve into bike shedding 
>> 
>>  
>> and acrimony." Sadly, an example of this can be found in the current 
>> discussion of dropping Python 3.8 support in 
>> https://github.com/sagemath/sage/pull/35404 with emotions running so 
>> high that sage-abuse had to step in. Adopting a version policy would 
>> prevent such discussions. On the other hand, by following a given policy, 
>> we would loose some flexibility.
>> 2. The main idea of NEP 29 is to have a community-wide standard. It is 
>> followed by many scientific packages such as Scipy, Matplotlib, IPython, 
>> Jupyter, Pandas, scikit, astropy, cuda, cirq, jax, pytorch among others. The 
>> adoption of NEP 29 will harmonize Sage's deprecation policy with these 
>> other major libraries. 
>> 3. The NEP 29 drop schedule is much faster than the EOL schedule of 
>> Python itself. Python 3.8 is supported until 2024-10, but NEP 29 already 
>> drops it 2023-04. However, adhering to the EOL schedule would prevent us to 
>> updating these packages that follow NEP 29.
>> 4. The NEP 29 schedule is about one release cycle faster than the 
>> previous drops (e.g. Python 3.7 support was dropped in Sage 9.7 while 
>> according to NEP 29 it would have been Sage 9.6).
>> 5. The faster drop schedule will free developer resources (less systems 
>> to test) and potentially increase developer productivity as it allows us to 
>> use newer language features.
>> 6. The faster drop schedule might be inconvenient for users who rely on 
>> older Python versions. To some extend this is remedied by our python 
>> install package, and relatively straightforward upgrade paths on most 
>> system. One should also note that users relying on other scientific python 
>> packages are likely forced to upgrade anyway, since these other packages 
>> likely follow NEP 29.
>> 7. The faster drop schedule would force users to upgrade to newer Python 
>> versions and thereby profit from fewer bugs and security issues. It is 
>> however questionable if Sage should play this educator role.
>> 8. One of the main goals of NEP 29 is to improve downstream project 
>> planning by having a community-wide standard. This is currently not very 
>> relevant for us as Sage is currently upstream of nothing except for some 
>> user packages. With the modularization effort, this may change in the 
>> future.
>> 9. There are not many other documented policies. As said above, most 
>> scientific python projects follow NEP 29. Most projects in web 

[sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Monday, June 3, 2024 at 8:16:30 PM UTC+1 Matthias Koeppe wrote:

Unlikely that we would add a package to the Sage distribution that builds a 
Rust library from source. 

Not so long ago we added support for installing Python packages from 
platform-independent wheels. We did this to sidestep the concern of 
shipping more and more of Javascript (Node.js) infrastructure that is 
needed for building JupyterLab components.

Likewise, we will soon add support for installing Python packages from 
platform-dependent wheels. This is needed for updating some Jupyter 
components that have started to use Rust (https://github.com/crate-py/rpds, 
a dependency of jsonschema).


Could you be more specific on this, please? There are different way this 
can be interpreted. Where would these wheels come from? From PyPI?

 

 
(In the Sage distribution, they won't be "pip" packages -- which are an 
underdeveloped mechanism in the build system of the Sage distribution -- 
but rather a variant of the existing "wheel" packages.)

As the upstream developer, you would publish binary wheels to PyPI, likely 
in the same way as is done in 
https://github.com/crate-py/rpds/blob/main/.github/workflows/CI.yml



On Saturday, June 1, 2024 at 4:46:14 AM UTC-7 Jing Guo wrote:

Dear all,

Recently we released a library for counting graph homomorphisms [0] in 
Sage. Due to performance and parallelism reasons, I was considering the 
possibility of re-writing some/all of the algorithms in Rust. I found a 
Rust library called `pyo3` [1] seems to be good for Python-Rust interop.

The latest post I could found is from one year ago [2], so I was wondering 
what the current status of possibility of integrating libraries written in 
Rust into Sage? Is the recommended approach still to make it an optional 
package? For instance, what I have something in mind is like `addcombq` [3] 
-- a Rust library which is callable from Sage/Python.

Many thanks!

Jing

[0]: https://github.com/guojing0/count-graph-homs
[1]: https://github.com/PyO3/pyo3
[2]: https://groups.google.com/g/sage-devel/c/OpBIfmbOlPA/m/hFKTdyE4CgAJ
[3]: https://github.com/Torrencem/addcombq

-- 
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/dddb2979-c656-4668-bc6b-43fe00eb5b95n%40googlegroups.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On 4 June 2024 18:46:44 BST, kcrisman  wrote:
>
>
>Yes. I am all for removing "no internet connection" assumption in 
>installing the sage distribution from source.
>
>
>Since we don't ship binaries, I'd like to hear from those who have had to 
>install Sage in circumstances with slow/no internet situations about this 
>(e.g. several of our French developers have had to do so in Francophone 
>Africa, if I recall correctly).  Perhaps this is no longer an issue, but it 
>would be nice to have confirmation.  I do agree that the issue of "certain 
>customers" needing no-internet installation should no longer be a 
>consideration.

There is absolutely no need to create huge tarfiles if you have to work offline 
with a collection of Pyhton packages (e.g. the collection of Sage packages); 
there are tools out there to creates offline mirrors of a collection of PyPI 
packages, such as Morgan:


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/CF683C3C-5A4B-4E75-A579-196B795A4F53%40gmail.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On Monday, June 3, 2024 at 9:10:56 PM UTC+1 Matthias Koeppe wrote:

On Monday, June 3, 2024 at 12:41:41 PM UTC-7 Michael Orlitzky wrote:

Rust is not nearly as portable as C, and has an unstable ABI that makes 
shipping compatible versions of packages from multiple sources nearly 
impossible.


I share this concern about ABI compatibility, and would therefore for now 
like a policy that restricts the use of such binary packages to
- optional packages 
- semi-standard, i.e., "disablable", packages such as the Jupyter frontend.

How about not inventing more "semi-", "quasi-", etc. here, and just go on 
with my proposal to allow standard pip packages?

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/1551dead-28ac-4041-9a48-b6f1764940bfn%40googlegroups.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

On 3 June 2024 23:47:14 CEST, Kwankyu Lee  wrote:
>
>
>Likewise, we will soon add support for installing Python packages from 
>platform-dependent wheels. This is needed for updating some Jupyter 
>components that have started to use Rust (https://github.com/crate-py/rpds, 
>a dependency of jsonschema).
>
>
>First sorry for an off-topic comment. If we need a feature (installing 
>Python packages from platform-dependent wheels) just to maintain jupyter, 
>then I think we should consider first removing jupyter from sage packages. 
>As far as I know, there is no technical reason why we have to ship jupyter, 
>we do it just because sage aims for "batteries included" assuming no 
>internet connection. But jupyter is too big to carry as a battery. 

There is no need to remove it - it suffices to convert it to a pip package. 
(yes, for this we need to allow standard pip packages - as I have been 
proposing).

Removing won't be very easy, as some parts of Jupyter are used by Sphinx. 
(doable, yes).

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/48839DF8-E517-4754-8D4E-6ABEC8C12A04%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make pytest, pytest_mock, pytest_xdist + dependencies standard packages

[Dima Pasechnik]

I don't argue against making them standard - I argue against vendoring them, 
which buys us essentially nothing but an extra headache.



On 1 June 2024 15:10:21 CEST, Nathan Dunfield  wrote:
>The six packages proposed for addition are all pure-Python and collectively 
>take up 4M installed (about a 450K download); for scale, I think a full 
>Sage installation is about 3G (1.25G download).  They all seem to be 
>well-maintained, and common enough that all are available on conda-forge.  
>Using pytest to test Sage sounds like a good thing to me, and I think it 
>makes sense to promote them standard packages.
>
>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/c5ab0d5a-55c0-4f55-abc1-60b4f23b6ad4n%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/A3CBA6CF-2C59-42EA-AB9D-5C5D6FB9EA8A%40gmail.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

On 1 June 2024 15:50:56 CEST, Nathan Dunfield  wrote:
>On Friday, May 31, 2024 at 11:38:34 AM UTC-5 Dima Pasechnik wrote:
>
>Before looking at 
>https://groups.google.com/g/sage-devel/c/lPLoA7zaoyg/m/dGE1B1jQEQAJ
>we should look at this proposal again, as pytest is a very suitable 
>candidate for the kinds of packages (standard pip packages)
>proposed here.
>
>
>Indeed, nothing (save for a very marginal case of a complete offline 
>install - and this can be helped if there is a will to allow such packages)
>is gained by mechanically adding the  pytest dependencies into Sage the 
>distro. 
>
>
>And doing this an extra code bloat, with stuff we don't patch, and don't 
>even know what's there.
>E.g. we can add a backdoored,or otherwise broken, version of one of these 
>into the distro, giving it extra legitimacy for no reason.
>
>
>If we kept pytest as a pip package, and did not explicitly add its 
>additional dependencies (iniconfig and exceptiongroup), that makes it 
>harder to quickly check whether a backdoored/broken package is even part of 
>Sage.
Once you have backdoored core in your project, the onus is on you to clean up 
the mess.
So it's better not to have the unknown to you code in the project. We don't 
want to take on extra responsibility like this.

Only "real" distros (Linux distros, Conda, etc) keep their own copies of pytest.
I don't know any Python project that does the same.
Please don't pull Sage towards being a "real" distro.
This shifts the focus away from what the project is about.

>
>Also, in the original discussion in this thread in February, some argued 
>that there was no reason to pin the version of pytest.  As Matthias points 
>out elsewhere, since then the release of pytest 8.* broke Sage's 
>preliminary pytest support [1]. 

we can pin versions of (optional) pip packages, so this doesn't seem to be a 
problem.
Such pinning can be done very quickly - if needed.

Dima

>
>Best,
>
>Nathan
>
>[1] https://github.com/sagemath/sage/pull/37999
>

-- 
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/68740A91-331C-4190-A432-5DA3FB499E7C%40gmail.com.

Re: [sage-devel] Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

PS. I realised that pyo3 is an option too. 

On 1 June 2024 14:35:23 CEST, Dima Pasechnik  wrote:
>Hi,
>
>pyo3 seems to be for calling Python from Rust. You need the opposite, Rust 
>from Python, e.g. as described in
><https://bheisler.github.io/post/calling-rust-in-python/>
>Making a PyPI (pip) package seems to be the most obvious option.
>With the current (outdated, I think) policies it will not be possible to make 
>such a package standard part of Sage (but I am gathering support for relaxing 
>these policies - see the thread on standard pip packages - that's what would 
>be needed).
>
>HTH,
>Dima
>
>
>
>On 1 June 2024 13:46:14 CEST, Jing Guo  wrote:
>>Dear all,
>>
>>Recently we released a library for counting graph homomorphisms [0] in 
>>Sage. Due to performance and parallelism reasons, I was considering the 
>>possibility of re-writing some/all of the algorithms in Rust. I found a 
>>Rust library called `pyo3` [1] seems to be good for Python-Rust interop.
>>
>>The latest post I could found is from one year ago [2], so I was wondering 
>>what the current status of possibility of integrating libraries written in 
>>Rust into Sage? Is the recommended approach still to make it an optional 
>>package? For instance, what I have something in mind is like `addcombq` [3] 
>>-- a Rust library which is callable from Sage/Python.
>>
>>Many thanks!
>>
>>Jing
>>
>>[0]: https://github.com/guojing0/count-graph-homs
>>[1]: https://github.com/PyO3/pyo3
>>[2]: https://groups.google.com/g/sage-devel/c/OpBIfmbOlPA/m/hFKTdyE4CgAJ
>>[3]: https://github.com/Torrencem/addcombq
>>
>>-- 
>>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/604dc1b9-d5ae-48bc-a181-dd9007ff3082n%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/EFEB925F-11D4-4AB0-AAB7-39D458949B12%40gmail.com.

Re: [sage-devel] Current status of possibility of integrating libraries written in Rust into Sage

[Dima Pasechnik]

Hi,

pyo3 seems to be for calling Python from Rust. You need the opposite, Rust from 
Python, e.g. as described in

Making a PyPI (pip) package seems to be the most obvious option.
With the current (outdated, I think) policies it will not be possible to make 
such a package standard part of Sage (but I am gathering support for relaxing 
these policies - see the thread on standard pip packages - that's what would be 
needed).

HTH,
Dima



On 1 June 2024 13:46:14 CEST, Jing Guo  wrote:
>Dear all,
>
>Recently we released a library for counting graph homomorphisms [0] in 
>Sage. Due to performance and parallelism reasons, I was considering the 
>possibility of re-writing some/all of the algorithms in Rust. I found a 
>Rust library called `pyo3` [1] seems to be good for Python-Rust interop.
>
>The latest post I could found is from one year ago [2], so I was wondering 
>what the current status of possibility of integrating libraries written in 
>Rust into Sage? Is the recommended approach still to make it an optional 
>package? For instance, what I have something in mind is like `addcombq` [3] 
>-- a Rust library which is callable from Sage/Python.
>
>Many thanks!
>
>Jing
>
>[0]: https://github.com/guojing0/count-graph-homs
>[1]: https://github.com/PyO3/pyo3
>[2]: https://groups.google.com/g/sage-devel/c/OpBIfmbOlPA/m/hFKTdyE4CgAJ
>[3]: https://github.com/Torrencem/addcombq
>
>-- 
>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/604dc1b9-d5ae-48bc-a181-dd9007ff3082n%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/DE2098C6-DECD-4A6B-8C18-C68CDD125281%40gmail.com.

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Dima Pasechnik]

Before looking at 
https://groups.google.com/g/sage-devel/c/lPLoA7zaoyg/m/dGE1B1jQEQAJ
we should look at this proposal again, as pytest is a very suitable 
candidate for the kinds of packages (standard pip packages)
proposed here.

Indeed, nothing (save for a very marginal case of a complete offline 
install - and this can be helped if there is a will to allow such packages)
is gained by mechanically adding the  pytest dependencies into Sage the 
distro.

And doing this an extra code bloat, with stuff we don't patch, and don't 
even know what's there.
E.g. we can add a backdoored,or otherwise broken, version of one of these 
into the distro, giving it extra legitimacy for no reason. 

 Dima

On Sunday, February 11, 2024 at 7:23:42 PM UTC Dima Pasechnik wrote:

> Currently the standard packages cannot be pip packages, i.e. we must, in 
> effect, vendor them. This entails an extra effort which is often not 
> needed, in particular as we patch only very few Python packages.
> Pip packages are on the other hand installed straight from PyPI.
>
> Good examples of standard packages which can become pip ones are tox, 
> pytest (not yet standard).
>
>
> The other difference is that by default these packages are not included in 
> the Sage releases source tarball.
>
> Rather than adding them there I propose to split the upstream/* part of 
> the tarball into something optional - which is represented by a list of 
> files to download, and which is just not needed if you build while 
> connected to the internet.
>
> This is a huge saving on the tarball size: with upstream/* in, Sage 10.2 
> tarball is 1.3Gb, and without it is smaller than 0.25Gb.
>
> Note that as William writes, the desire to have Sage buildable without an 
> internet connection was a requirement by a past Sage funder, gone about 10 
> years ago. Thus there's no longer an obligation to have this option.
> I am not aware of a similar to Sage which provides tarballs allowing for 
> an offline build.
>
> Thus, I would like to call a vote on these two topics:
>
> 1) allow standard packages to be pip packages 
>
> 2) drop the contents of upstream/ from the Sage source tarballs.
>
>
> ---
> 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/77996190-28c2-4a88-a49c-3b4f28edff01n%40googlegroups.com.

Re: [sage-devel] Proposal (redo): Make pytest, pytest_mock, pytest_xdist + dependencies standard packages

[Dima Pasechnik]

On Thu, May 30, 2024 at 11:25 PM Matthias Koeppe
 wrote:
>
> We added the packages as optional "pip" packages (see 
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>  for the terminology), each more than 1 year ago.
>
> - 
> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest#spkg-pytest
>  (added in 2020)
> - 
> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_mock#spkg-pytest-mock
>  (added in 2022)
> - 
> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_xdist#spkg-pytest-xdist
>  (added in 2022)
>
> "pytest" is the current gold standard for running tests of Python packages. 
> Various standard packages in the Sage distribution already declare pytest in 
> "dependencies_check" as a conditional dependency for use when SAGE_CHECK=yes 
> is set. The support for testing parts of the Sage library with pytest was 
> from an effort largely stalled after 2022 -- and which has been completely 
> broken since early 2024 with the arrival of pytest 8.x, which I have just 
> fixed in https://github.com/sagemath/sage/pull/37999 (to be merged). I'll 
> note that recent versions of pytest have added support for PEP-420 implicit 
> namespace package, which the Sage library uses as part of the modularization 
> effort.
>
> By making pytest a standard package, I would hope to help revive this effort, 
> and thus the larger effort to "adopt mainstream Python testing/linting 
> infrastructure" (see https://github.com/sagemath/sage/issues/28936).
>
> I'm proposing to make the packages (and their dependencies) standard (wheel) 
> packages according to the procedures in our developer guide.
> - Reference to previous such proposals following our project's procedures: 
> https://groups.google.com/g/sage-devel/c/EMeTJ6Hwgns/m/KyOOQzkzAAAJ
> - Link to our packaging documentation and explanation how making it a 
> standard package compares to version pinning done for example using 
> conda-lock:  
> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/N2vuKb-TAAAJ
>
> The other pytest_* packages are related technical packages.
> The PR that implements it: https://github.com/sagemath/sage/pull/37301
>
> This is a redo of the 2nd part of my proposal 
> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ from Feb 
> 10, which was stalled. (The 1st part (on python_build) was redone in 
> https://groups.google.com/g/sage-devel/c/EMeTJ6Hwgns/m/9_zh6usoAAAJ and 
> approved.)

My objections (and not only my) to this still stand - and, frankly, I
don't see anything new here. What's the point of bringing the stalled
matters up again in this original unchanged way ?

We don't need to have all the dependencies of packages like pytest in
Sage, it's just pure bloat, give their peripheral role in particular.
That is, it's fine to declare them standard, and keep them pip
packages - what do we lose this way? Nothing, and we don't bloat Sage
with even more packages nobody knows anything about - besides them
being dependencies of something in Sage.

But there is more trouble ahead if the currect proposal gets in over
my objections. Say, the next version of pytest might  get a part which
needs Rust, and pytest is a wheel package, with all its buildable from
source dependencies in Sage, and Sage is fully committed to using
pytest for testing.
Are you going to include a Rust toolchain in Sage ? No, obviously not.
Are you going to demote pytest back to optional,
and throw away work done on using pytest more? No. Have another fight
over the ways Sage should be packaged? Yes, sure.

I think the only feasible way forward here is as I proposed (standard
pip packages), and I propose it again.

Dima

>
>
> I ask everyone to focus on the specifics of this proposal.
>
> --
> 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/2c42bd41-24a3-467e-857f-aedc3966c107n%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/CAAWYfq2fubG32GKjKroEVJ_LKB2WUY%2BqJSXCZTgd0ROC%3DYHczA%40mail.gmail.com.

Re: [sage-devel] Re: Cannot build sage 10.4.beta6 [fflas_ffpack-2.5.0]

[Dima Pasechnik]

On Wed, May 22, 2024 at 4:48 AM Edgar Costa  wrote:
>
> I ended up only needing the first combined with `--with-system-flint=no`

can you skip `--with-system-flint=no` with your latest Homebrew's flint 3.1.3 ?

>
> On Tuesday, May 21, 2024 at 9:53:07 AM UTC-4 Kwankyu Lee wrote:
>>
>> You need
>>
>> https://github.com/sagemath/sage/pull/38025
>>
>> and possibly also
>>
>> https://github.com/sagemath/sage/pull/38021
>>
>> On Tuesday, May 21, 2024 at 9:44:30 PM UTC+9 Edgar Costa wrote:
>>>
>>> Hello,
>>>
>>> Does someone has insights how t fix this?
>>> I already told ./configure --with-system-givaro=no and removed my installed 
>>> givaro via homebrew.
>>>
>>> You can find the logs here: 
>>> https://gist.github.com/edgarcosta/32a8dd533cf88b937fa54194da7efe8d
>>> But the main issue is here:
>>> [fflas_ffpack-2.5.0] [spkg-install]   "Givaro::Integer::operator-(long 
>>> long) const", referenced from:
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic>> void> >(Givaro::Modular const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::Modular const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   "Givaro::Integer::operator>>(int) 
>>> const", referenced from:
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install]   double 
>>> FFLAS::Protected::computeFactorClassic 
>>> >(Givaro::ModularBalanced const&) in ffpack_inst.o
>>> [fflas_ffpack-2.5.0] [spkg-install] ld: symbol(s) not found for 
>>> architecture x86_64
>>>
>>>
>>> Thank you,
>>> Edgar
>>>
>>>
> --
> 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/d1f6b536-4312-4e72-92c2-5ad6d38b5f13n%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/CAAWYfq3mE%3D01K5Rt69b%2BOTwrtg8WGoKduS5uNHfdVfpa5M5vAw%40mail.gmail.com.

Re: [sage-devel] Re: Standard/Recommended practices for adding codes with third-party libraries into Sage codebase?

[Dima Pasechnik]

On Mon, May 20, 2024 at 3:43 AM Matthias Koeppe
 wrote:
>
> On Sunday, May 19, 2024 at 12:53:25 PM UTC-7 Jing Guo wrote:
>
> In the past few months I have been working on a Sage library for counting 
> graph homomorphisms: https://github.com/guojing0/count-graph-homs (It's still 
> updating, hence not 100% complete)
>
> In `concurrent_hom_count.py`, I use third-party libraries, such as `numba`, 
> `dask`, and `numpy`. For numpy, I think it's already in Sage. So I was 
> wondering what would be the standard/best/recommended practices if I want to 
> contribute this code to Sage, which I suppose does not support either `numba` 
> or `dask` (searching in the codebase returns nothing)?
>
>
> It depends on the intended degree of integration into Sage.
> The loosest integration: Prepare it as a pip-installable package (which 
> declares its dependencies using the standard Python packaging practices);  
> then add it as an optional "pip" package to the Sage disitribution.

How exactly is this code using Sage - what are graph Sage-specific
functions used?
Tight integration with Sage would need, in the present Sage distro
model, numbda and dask as its packages, and in particular numba would
be very tricky, as it needs LLVM.

> See Meta-ticket: Add external user packages as optional/experimental packages 
> (https://github.com/sagemath/sage/issues/31164) for examples and pointers to 
> documentation.
>
> --
> 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/d29caf89-d6b5-4896-94b1-b4703218e857n%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/CAAWYfq2ZLpQ-s8eDmwcZUtAccN42UJOYWt_%2B_qJ_v20d8fka4g%40mail.gmail.com.

Re: [sage-devel] Re: approve github actions

[Dima Pasechnik]

On 15 May 2024 02:14:05 BST, David Roe  wrote:
>On Tue, May 14, 2024 at 9:13 PM Dima Pasechnik  wrote:
>
>>
>>
>> On 14 May 2024 22:55:01 BST, "julian...@fsfe.org" 
>> wrote:
>> >I granted "write" permissions to you. That seems to be the required
>> >permission to approve workflow runs.
>>
>> IIRC, such permissions are automatic for the members of triage team.
>>
>
>That's incorrect.  Triage is a lower permission level than Write; see here
><https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization>
>for more details.



"Write" has commit rights beyond doing PRs.
I don't think such permissions are needed to authorise CI runs. AFAIK, any 
member of "triage" can do the latter - unless this recently changed.







>David
>
>Could you check that Martin is there?
>> >
>> >Can you check that it works now?
>> >
>> >julian
>> >
>> >PS: If this should be done differently, please let me know and I'll
>> revoke
>> >that permission again :)
>> >
>> >On Tuesday, May 14, 2024 at 11:55:53 PM UTC+3 axio...@yahoo.de wrote:
>> >
>> >> Could I have the right to approve github actions?
>> >>
>> >> Otherwise, mentoring the GSOC student over github is a pain.
>> >>
>> >> Best wishes,
>> >>
>> >> Martin (mantepse)
>> >>
>> >
>>
>> --
>> 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/0F49C387-A1D9-4517-A840-14DFD2A84BA9%40gmail.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/6B1DD841-1773-4E9F-9080-F47340B1B09C%40gmail.com.

Re: [sage-devel] Re: approve github actions

[Dima Pasechnik]

On 14 May 2024 22:55:01 BST, "julian...@fsfe.org"  wrote:
>I granted "write" permissions to you. That seems to be the required 
>permission to approve workflow runs.

IIRC, such permissions are automatic for the members of triage team.
Could you check that Martin is there?
>
>Can you check that it works now?
>
>julian
>
>PS: If this should be done differently, please let me know and I'll revoke 
>that permission again :)
>
>On Tuesday, May 14, 2024 at 11:55:53 PM UTC+3 axio...@yahoo.de wrote:
>
>> Could I have the right to approve github actions?
>>
>> Otherwise, mentoring the GSOC student over github is a pain.
>>
>> Best wishes,
>>
>> Martin (mantepse)
>>
>

-- 
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/0F49C387-A1D9-4517-A840-14DFD2A84BA9%40gmail.com.

Re: [sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[Dima Pasechnik]

On Tue, May 14, 2024 at 1:48 AM Matthias Koeppe
 wrote:
>
> On Sunday, May 12, 2024 at 6:50:05 PM UTC-7 Travis Scrimshaw wrote:
>
> That model is not how we have worked as a community, nor do I think it is a 
> productive way to run a smaller developer community such as ours.
>
>
> I'm not sure what your reference point may be for this description, but in my 
> experience it has not been remotely like this ever since I started 
> contributing to Sage (2015). The project's infrastructure (in the past, for 
> example Trac or the patchbot) has been run by volunteer administrators; the 
> wiki page https://github.com/sagemath/sage/wiki/Infrastructure is intended to 
> keep track of it (though much info is likely outdated), and there is a closed 
> mailing list "sagemath-admins" for those involved.
>
> Perhaps a good reference: 
> https://www.redhat.com/en/blog/understanding-open-source-governance-models

It does not look Sage clearly fits into one of their types. Anyhow,
RedHat (wholly owned by IBM nowadays) is known to be subverting open
source in general,
and GPL in particular, for years. I would take whatever they write on
this topic with a very big grain of salt, as it might be merely
creating more open-source FUD.
Cf. https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/

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/e0c30573-7e4b-4991-a70f-53659d268571n%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/CAAWYfq3WY66LofuVrA11POVCM7e2E3%2B3JgdLK7D8yzz0dXYt9g%40mail.gmail.com.

Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Sunday, May 12, 2024 at 4:42:42 PM UTC+1 Matthias Koeppe wrote:


On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote:

If I read your proposal correctly, it is about removing review from changes 
made by "maintainers" [...]


That's right -- for the specified files.

Mostly, I am opposed to this because changes to the files you list are not 
automatically uncontroversial, see the disputed 
https://github.com/sagemath/sage/pull/37740, 
https://github.com/sagemath/sage/pull/37387, 
https://github.com/sagemath/sage/pull/37351, 
https://github.com/sagemath/sage/pull/36726, 
https://github.com/sagemath/sage/pull/36697, 
https://github.com/sagemath/sage/pull/36694, 
https://github.com/sagemath/sage/pull/36678, (there's probably more.)


Well, my proposal only generally noted that "waiting for reviewers to 
approve a PR and waiting for the Release Manager to merge it adds too much 
delay and friction." But yes, these "disputes" are certainly part of the 
friction that my proposal seeks to eliminate by establishing proper 
governance.

But since you bring it up and list these examples, yes, we can certainly 
have this conversation in more detail.

[...] In general, I am not sure about changing the review requirements. I 
know that having to do several rounds of review can be frustrating. At the 
same time, I like the idea of having somebody double check things. (I 
consider waiting for the first round of review a necessary annoyance. What 
can be really frustrating is waiting for the second round of review. Maybe, 
there are other ways to improve this, e.g., by encouraging people to set 
things to "feel free to set to positive review yourself once you addressed 
these tiny things I brought up in my review.")


I have to note that this description would not be a good starting point for 
a conversation. First of all, it makes me uncomfortable that you are 
sharing generalities about the PR review process, perhaps as if I needed 
advice on this from you; what could be the possible purpose of doing so? 
The topic here is much more specific: namely PRs that make changes to the 
CI. 
But more importantly, you are writing this after having just brought up PRs 
such as "CI Linux: Replace use of pkill" (
https://github.com/sagemath/sage/pull/36726) -- which you as member of the 
sage-conduct committee are familiar with in detail. In this context, 
mentioning something like "waiting for the second round of review" as 
"really frustrating" furthers a mischaracterization of the problem, 
trivializing a very serious matter.


"CI Linux: Replace use of pkill" (
https://github.com/sagemath/sage/pull/36726), more precisely, the 
discussion (the non-flamewar part of it) which went on there,
is an excellent example of CI importance blown out of proportion.

It was argued there that certain "minimal configurations" of packages are 
crucial for Sage development, where in reality no sane users would build 
Sage on such a super-minimal set of packages. These "minimal 
configurations" are kept as an excuse for not slimming down Sage the distro 
to a  more meaningful set of packages, e.g. not including largely useless 
parts such as the gcc compiler.

If, as proposed, the governance of the CI part of the Sage the distro is 
getting split off from Sage the distro, but kept inside Sage proper,
it will only make CI more dominant, not less, and lead to more disputes, 
not less. The CI should be, basically, a downstream 
quality assurance tool, not the means in itself. It should not dictate what 
packages Sage should or should not vendor, and what versions
of Python etc Sage must support.

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/206a5801-dda8-4857-b0ff-3fc915490847n%40googlegroups.com.

Re: [sage-devel] Re: New labels v: mimimal, v: small ... on pull requests

[Dima Pasechnik]

On 9 May 2024 22:46:17 BST, Travis Scrimshaw  wrote:
>I am *very* strongly opposed to these tags. Their cutoffs are arbitrary nor 
>they serve no useful purpose as far as I can tell. To this point, they do 
>not reflect the difficulty of a review; in fact, they are at best 
>counterproductive to finding reviewers because it might deter people from 
>reviewing "large" or "huge" changes as they can include lots of trivial 
>doctest changes. At best it is just additional clutter in all of the 
>information for PRs.

It's also discouraging word, "minimal" - you do a "minimal" PR like 

- which potentially implies that we have thousands of missing "volatile" 
declarations in Cython code interfacing libgap, libsingular, and other 
libraries using setjmp/longjmp mechanics to gracefully process errors.


>
>From a community perspective, I feel such changes should have been brought 
>to the attention of sage-devel once the PR was at a positive review. 
>Specifically, *before* the PR was merged. Not everyone has time to read 
>every PR, and a small consensus of developers might not reflect the 
>development community at-large when making changes like this.
>
>Best,
>Travis
>
>
>On Tuesday, May 7, 2024 at 3:12:27 PM UTC+9 seb@gmail.com wrote:
>
>> Dear Sage developers,
>>
>> You may have noticed that since yesterday a new type of labels with the 
>> `v:` prefix has appeared on our PRs. These are automatically set to 
>> classify PRs based on their size. For more information, see #37262 
>> .
>>
>> Sebastian
>>
>

-- 
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/A5AA8226-A33F-46DA-AE56-4B66A014930F%40gmail.com.

Re: [sage-devel] Re: Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

I've already said while the previous version of this was discussed, is
that it's a huge mess to have different commit rights for different
parts of the tree, and I proposed to spin the CI into a separate
repository, as an alternative which simplifies a lot of things.

Dima


On Wed, May 8, 2024 at 7:25 PM Matthias Koeppe  wrote:
>
> On Monday, May 6, 2024 at 10:49:07 PM UTC-7 Kwankyu Lee wrote:
>
> I propose a governance change for a small part of the main Sage repository:
> 1. The directories .ci, .devcontainer, .github/workflows. [...]
> 2. The file tox.ini. [...]
>
> 3. The file src/doc/en/developer/portability_platform_table.rst (which I 
> update using "tox -e update_docker_platforms").
>
>
> I think we should restrict the scope to the files and directories strictly in 
> the CI infrastructure.  Anything under `src/` should be excluded.
>
>
> This file src/doc/en/developer/portability_platform_table.rst is part of the 
> documentation of the CI infrastructure and needs to be updated (by script) 
> whenever I make changes to the tested platforms.
>
>
>
> Proposed change: All changes to these files are made through PRs. When the PR 
> is ready, a developer in the Maintainer role directly merges the PR into the 
> "develop" branch. In other words, switch to the "Show" model for these 
> changes.
>
>
> I fear that developers in the Maintainer role could conflict in making 
> changes to the CI-related files, as we suffered in the disputed PRs.
>
>
> I don't share this concern.
>
> By the way, I documented who is currently in the Maintainer role when I 
> prepared the NumFOCUS application last month, see 
> https://github.com/sagemath/sage/wiki/NumFOCUS#q13new-please-list-your-projects-maintainers-ie-anyone-with-write-access-to-the-repository
> (I haven't checked if it has changed since.)
>
> There's certainly a broader governance discussion that we should have at some 
> point (regarding duties and appointment procedures for the Maintainer role, 
> the Triage team, and other functions in the project), but I would suggest to 
> do this in a separate thread.
>
> So I suggest to have only one Maintainer for those files. As we acknowledge a 
> certain dictatorship of the release manager, we may have a vote to elect the 
> CI manager and give him/her a restricted dictatorship and responsibility.
>
>
> This model would also work for me, but I think it's unnecessarily specific.
>
> --
> 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/e955c1d9-96f5-495d-85a9-9267f5414d3dn%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/CAAWYfq3h3f0G4JFxwFt02A%3D55xOLeDcNggWkjfUhWH8SRC3PPA%40mail.gmail.com.

[sage-devel] Re: testing optional packages

[Dima Pasechnik]

As I already told Marc, one should use "pytest" rather than "sage -t" - for 
obvious reasons: Sage has very own testing system,
and one should not expect it to be able to test non-Sage code. 

On Monday, April 29, 2024 at 1:08:01 PM UTC+1 Marc Culler wrote:

> I don't know what the expectations are for testing optional packages, but 
> in 10.4.beta4 when I run:
>
> ./sage -t venv/lib/python3.11/site-packages/symengine
>
> I get the exception:
>
> NameError: name 'test_sage_conversions' is not defined
>
> - 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/2b7b37d7-df3c-4288-91f6-0f055c5d3b25n%40googlegroups.com.

Re: [sage-devel] Re: wasm

[Dima Pasechnik]

It's interesting to compare this with the development by cocalc people, cowasm 


Perhaps William can explain the differences.


On 30 April 2024 18:00:26 BST, Matthias Koeppe  wrote:
>Hi Doris,
>porting Sage to pyodide is in progress, see 
>https://github.com/sagemath/sage/issues/34539, but it's not ready to be 
>used for what you have in mind. 
>I second Oscar's suggestion to look into using *sympy* and/or *python-flint*
>.
>
>The current status of the Sage pyodide port:
>- Some key dependencies of Sage will be shipped with the next pyodide 
>release (0.26): *ipython*, *cysignals*, *ppl*/*pplpy*, *flint*, 
>*memory_allocator*
>- https://github.com/pyodide/pyodide/pull/4438 provides the fundamental 
>modularized distribution packages *sagemath-objects*, *sagemath-categories*, 
>*sagemath-environment*, *sagemath-repl*
>
>The current bottlenecks / next steps:
>- *pari*, *cypari2* (https://github.com/pyodide/pyodide/pull/4430; help 
>wanted)
>- Adding the modularized distribution packages that provide more parts of 
>Sage, in particular *sagemath-pari* and *sagemath-flint*: 
>https://github.com/sagemath/sage/pull/37900, 
>https://github.com/sagemath/sage/pull/37901 
>(needs review)
>
>Matthias
>
>On Tuesday, April 30, 2024 at 12:29:35 AM UTC-7 Doris Behrendt wrote:
>
>> Hi all,
>>
>> My team is about to develop a webapp where we want to factor polynomials 
>> with coefficients in ZZ.
>> We want to offer a dropdown menu where the user can select the base ring 
>> and then the factorisation changes interactively. We use React and 
>> JavaScript and also Web Assembly, e.g. for our Web-OpenSSL here: 
>> https://www.cryptool.org/en/cto/openssl/
>>
>> Sage offers the command change_ring, we did not find a JavaScript Library 
>> that has this functionality. So I thought, perhaps we could look for 
>> solutions where Sage is used together with web assembly.
>>
>> After some research I have the impression that there are some proofs of 
>> concept, but there is nothing actively developed?
>>
>> Since I am not a programmer and nobody in my team is a mathematician (so 
>> my developers don't know Sage), I kindly ask on this list for any hints how 
>> we could proceed?
>>
>> Thanks in advance
>> Doris
>
>-- 
>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/91eec8d3-9173-46f7-9d64-4362598ee8f8n%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/1E6E3EC4-78B2-46AA-A624-3EAB823A022E%40gmail.com.

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

[Dima Pasechnik]

On Fri, Apr 26, 2024 at 2:24 PM Georgi Guninski  wrote:
>
> On Thu, Feb 15, 2024 at 2:27 AM Dima Pasechnik  wrote:
> >
> > I've filed https://sourceforge.net/p/maxima/bugs/4262/
> >
>
> Is maxima supported?
> There is no progress on their bug system for more than 2 months.

not many people are involved, and some bugs stay open for years there.


> SEGV is not pleasant, but incorrect symbolic result casts doubts about
> all symbolic sage computations, especially those that can't be
> verified numerically.
>
> --
> 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/CAGUWgD_MWht0_wBwXXsH-c%3DpKGSXUCgNBEbKq4PyLRc3g5k%3D_Q%40mail.gmail.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/CAAWYfq0mzJCU2MOhgGFKZCfwNtMU0J3cuOmddWxGY6dEqqi9PA%40mail.gmail.com.

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

[Dima Pasechnik]

On Thu, Apr 25, 2024 at 4:36 PM  wrote:
>
> On Thu, Apr 25, 2024 at 07:03:29AM -0700, Marc Culler wrote:
> > On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
> >
> > Essential components of sagelib such as GAP, Singular, don't run on
> > native Windows
> >
> >
> > I was amused to find the following statement on the GAP forum
> > <https://www.gap-system.org/ForumArchive2/2005/000999.html> from 2005:

you might also like to know that in 2000 I asked whether we can have libgap :P
https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/using_GA.1/1.html

my 1st message to GAP Forum was sent in 1993:
https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/Re__brea.1/1.html


> >
> >   >  While porting GAP to use native Win32 calls is doable, basically
> > src/system.c is the only place
> >> that needs lots of changes, it is certainly a nontrivial and
> > time-consuming task. (and one needs
> >> to be a bit of an expert in programming to do this, IMHO)
> >
> > The author was someone from the Netherlands by the name of *Dima
> > Pasechnik.  :^)*
>
> It was me, yes. And I used to know from what end
> you have to approach a Windows machine. :-)
> But not to the point of knowing exactly how to change fork() and sbrk(),
> (and mmap()) into whatever functions with 15 arguments you have to use
> on Win32 as their replacements (they already have about 10 versions of
> spawn to use in place of fork).
>
> Note that since 2005 GAP has changed quite a bit, too.
> They made a go at making it multithreaded (HPC GAP), and that made code
> harder to deal with (HPC GAP is still beta).
> Instead of GAP's native GC (with its sbrk/mmap), HPC GAP uses Boehm GC, which 
> does run on native
> Windows. But it's a beta...
>
> Oh, and someone died porting GAP to Windows, some years ago.
>
> 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/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%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/CAAWYfq04q_KqiW_qEvPFRrqaHyC1Bf-a%3D1r1_bN3Lt0G61DqiA%40mail.gmail.com.

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

[Dima Pasechnik]

On 25 April 2024 14:47:35 BST, Marc Culler  wrote:
>On Thu, Apr 25, 2024 at 8:28 AM Dima Pasechnik  wrote:
>
>> On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield 
>> wrote:
>> >
>> > On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
>> >
>> > Yes, native Windows would clearly be a very important target.
>> >
>> >
>> > As a data point, downloads of our stand-alone SnapPy app, which is about
>> as high level pure math as it gets, are 60% higher for Windows than macOS.
>>
>> That's not for native Windows, that's for WSL, right?
>>
>
>Wrong!  SnapPy runs as a native Windows app.
>
>We build Pari with msys2 and mingw on a CI runner.
>
>Essential components of sagelib such as GAP, Singular, don't run on
>> native Windows (on Cygwin, yes, but
>> we know by now, Cygwin is too flaky for Sage to work) and I don't
>> think anyone is keen on
>> doing the hard work to port it.
>>
>
>Msys2 and mingw are not so flaky, and use more or less the same toolchain
>as Cygwin.  There are many ports of gnu libraries to msys2 which can be
>installed with their package manage (pacman).  I am not convinced that GAP,
>Singuler, etc. could not be built with mingw.

E.g. GAP uses sbrk, fork (which are not in msys2/mingw), you'll need to port 
their GC too.
Doable, but very, very far from easy.



>
>- 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/E442AC03-90B9-4167-81F4-AB0E9E3C20AE%40gmail.com.

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

[Dima Pasechnik]

On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield  wrote:
>
> On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
>
> Yes, native Windows would clearly be a very important target.
>
>
> As a data point, downloads of our stand-alone SnapPy app, which is about as 
> high level pure math as it gets, are 60% higher for Windows than macOS.

That's not for native Windows, that's for WSL, right?

Essential components of sagelib such as GAP, Singular, don't run on
native Windows (on Cygwin, yes, but
we know by now, Cygwin is too flaky for Sage to work) and I don't
think anyone is keen on
doing the hard work to port it.

This puts native  Windows  support into the area of wishful thinking.

 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/CAAWYfq3P-zGuoT%2B2x96oFBNeDCh%3DEzqmn9WgTGhPmH2akPp%3DcA%40mail.gmail.com.

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

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 9:29 PM Nathan Dunfield  wrote:
>
> 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 " 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.)

There isn't a big problem to set up a GitHub wheel builder for
CyPari2, so  there is not really a sea of difference here in this
sense.

Also, probably it should be mentioned that linux distro way/pip way
can be very nicely combined  using a python venv.
So one can use system packages, but add up more packages, and, if
needed, override system packages with other versions.


>
> 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.

-- 
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/CAAWYfq0oqXa1J4pJM78Mk8pb0YCyKMQfmFyp-NdpXQS6Yy_dRA%40mail.gmail.com.

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

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 2:11 PM Marc Culler  wrote:
>
> On Wednesday, April 24, 2024 at 8:05:15 AM UTC-5 Dima Pasechnik wrote:
>
> running Cython in sage prompt or in Sage Jupyter notebook has nothing
> to do with -i option.
>
>
> I realize that.  But it looked to me like those variables are being set in 
> the sage-env script *primarily* to support sage -i.  Perhaps you are right 
> that it is *primarily* to support compiling cython, but it doesn't look like 
> it to me.  In any case, on macOS the default vaues work fine.

sage -i actually calls make, on a makefile where everything is already
set up. So no, it's not for sage -i.
>
> - 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/9d670ddb-ba2d-4c60-9fc2-5b0c1c209e3cn%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/CAAWYfq3dEnrcBWkzii%3DLh82%3DA0h85oYaUeO%3DDxQPu89An6F94g%40mail.gmail.com.

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

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 3:37 PM Marc Culler  wrote:
>
> I think that CyPari ;and CyPari2 provide a relevant example.
>
> Some background ... CyPari is a PyPi package with binary wheels which 
> predates and was the starting point for Sage's cypari2 (hence the 2 in the 
> name).   The basis for CyPari was Sage's pari module.  That module was 
> modified to make it independent from the rest of Sage so that Sage's Pari 
> support could be provided as a component of SnapPy. Binary wheels for CyPari 
> are available for Windows, macOS and manylinux.  The current versions of 
> those wheels are statically linked against Pari 2.15.4
>
> The binary wheel for CyPari weighs in at 7MB.  Sage's CyPari2 is available as 
> a binay wheel for macOS and manylinux and the size is of the same order of 
> magnitude.  When they are unpacked and installed the sizes of these python 
> packages are respectively 19MB and 7.5MB (cypari2 is linked against the 
> dynamic libraries libgmp and libpari, which together are about 12MB and which 
> are external to the python package).  A full Sage installation is about 5 
> gigabytes.  With some significant omissions and compression of the 
> documentation, the macOS app squeezes that down to 3.4GB.
>
> So the size of this one significant self-contained component of sage is about 
> 200 times smaller than the full sage installation and it could be made 
> installable on Windows with some additional work which has already been done 
> for a very closely related package.

cypari2 is indeed self-contained (with libpari and libgmp added to the
count), and provides a Pari-Python interface.
This full installation takes about 35 Mb. But it's not a relevant
example, cause it's a very limited functionality.

This is unlike sagemath-graphs, etc, which are, as I wrote, very far
from being self-contained. Many of them, with all of its dependencies
installed, will be blow up to a good half of the whole Sage, if not
more.
So there are no 1%  savings on bandwidth here, more like 30%-50%, or less.

Dima
>
> - Marc
>
>
> On Wed, Apr 24, 2024 at 8:48 AM Oscar Benjamin  
> wrote:
>>
>> On Tue, 23 Apr 2024 at 15:27, Marc Culler  wrote:
>> >
>> > 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.
>>
>> Is the benefit in this case mainly about reduced disk/network usage?
>>
>> I could imagine other theoretical benefits like maybe some parts could
>> be installed natively on Windows or some parts might be easier to
>> provide binaries for etc.
>>
>> Are there any indicative numbers for what the size would be when
>> installing some useful portion of Sage vs installing the whole of
>> Sage?
>>
>> --
>> Oscar
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sage-devel/mqgtkLr2gXY/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAHVvXxQUanPY%3D1svhf7Q8xDFD5BroD9wTLRc1-wmFC3vQhBMRg%40mail.gmail.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/CALcZXREFctqVF8Hr1B%2Bmz9WfhV9Dspop5EmWN7Q%2BsYdJLvnh4w%40mail.gmail.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/CAAWYfq2PGYDXTUP-1uCsSefDTKr45QFNbLQOk9%3Dgsx6EBzF9QQ%40mail.gmail.com.

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

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 2:08 PM Kwankyu Lee  wrote:
>
> Wouldn't people in the python world who need a serious amount of math know of 
> sage anyway, and then, if they cannot rely on all of sage because that is too 
> large, use, for example, `citation.get_systems` to see whether they can do 
> without some dependencies?
>
>
>  I think they would do `pip install sagemath-graphs` if they need graphs 
> functionality.
"Too large" is relative. What was "too large" few years ago is normal
now, and RAM only gets cheaper, and 32-bit systems
get irrelevant.

And they'd be often quite unhappy, as e.g. basically nothing in
src/sage/graphs/generators/classical_geometries.py
will work without sage.rings or GAP.
Many other parts of sage.graphs use things in sage.combinat, as well
as cliquer, bliss/nauty, etc.

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/8dd2c1ce-7811-4ada-94cc-075d5b6ab93bn%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/CAAWYfq2sRJSntR33W5%3DQOo4rZH_AN0aOkTC%2BoKwAuHY1t6htOQ%40mail.gmail.com.

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

[Dima Pasechnik]

On Wed, Apr 24, 2024 at 4:45 AM Marc Culler  wrote:
>
> That was it!
>
> Thank you Gonzalo; indeed, it helps a lot.  And your workaround is fine, 
> since we don't support the -i option,

running Cython in sage prompt or in Sage Jupyter notebook has nothing
to do with -i option. One can call cythonize
in a regular Sage session (see, it builds a .so in /tmp):

sage: from sage.misc.cython import compile_and_load
sage: module = compile_and_load("def f(int n):\nreturn n*n")
sage: module.f(10)
100
sage: module




> 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.

Anyway, instead of calling these all the time (this was done in
https://github.com/sagemath/sage/issues/14296)
we can let ./configure to fill in @AS@, @LD@, etc templates in
build/bin/sage-build-env-config.in, and having the corresponding env.
vars.
initialised in build/bin/sage-build-env-config(.in).

Dima

>
> - 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.

-- 
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/CAAWYfq2mdRtbkp4FKPob2eKn-tXku0AV99mLPNvtD31Lg-0JHw%40mail.gmail.com.

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

[Dima Pasechnik]

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)

[Dima Pasechnik]

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 
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#dependencies-and-distribution-packages>
> (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 
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#doctest-only-dependencies>
> or 
>for providing advertised  
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>
>extra  
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>
>features 
><https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>.
> 
>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)

[Dima Pasechnik]

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)

[Dima Pasechnik]

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.

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

[Dima Pasechnik]

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

> On Sunday, April 21, 2024 at 2:30:15 AM UTC-7 Martin R wrote:
>
> Why would you separate mathematics into packages that have no more
> external dependencies from others, which at the same time may grow internal
> dependencies over time?
>
>
> 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:

>
> *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


> *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


>
> *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 ?


> *sagemath-groups*
> - non-Python dependency (via *sagemath-gap*): *gap* (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-gap/pyproject.toml.m4#L52
> *)*
> - non-Python dependency (via *sagemath-modules*): *gsl* (see above)
>
> *sagemath-polyhedra*
> - non-Python dependency (via *sagemath-glpk*): *glpk*
> - non-Python dependency (via *sagemath-modules*): *gsl* (see above)
> - Python runtime dependency: *pplpy*
>
> *sagemath-schemes*
> - non-Python dependency (via *sagemath-modules*): *gsl* (see above)
> - non-Python dependencies (via *sagemath-singular*, *sagemath-flint*,
> *sagemath-ntl*, *sagemath-pari*): singular, flint, ntl, pari (
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-pari/pyproject.toml.m4#L61
> )
> - Python dependency (via *sagemath-singular*, *sagemath-flint*,
> *sagemath-pari*): *cypari2*
> - Python dependency: *scipy*
>
> *sagemath-symbolics*
> - non-Python dependencies: *ecl*, *maxima*, *singular*
> https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-symbolics/pyproject.toml.m4#L89
> - non-Python dependencies (via *sagemath-flint*, *sagemath-ntl*,
> *sagemath-modules*): *flint*, *ntl*, *pari*, *gsl*
> - Python dependencies: *mpmath*, *sympy*, *cypari2, numpy*
>
> --
> 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/41d11d3f-d5e5-4bf5-9629-2ef17ce4d6b1n%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/CAAWYfq2NxJYaqQBfVrZTkUproapZNH7_Ci%3DZjnZVV0vXFCBdqw%40mail.gmail.com.

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

[Dima Pasechnik]

On 20 April 2024 19:34:49 BST, Matthias Koeppe  wrote:
>On Saturday, April 20, 2024 at 12:56:30 AM UTC-7 Martin R wrote:
>
>do I understand correctly that common lisp (via maxima) is the main 
>dependency that prevents sagemath from being pip-installable?
>
>
>No.
>
>For one, SageMath is already pip-installable. 
>That was one of the first deliverables of the modularization project, 
>completed in 2021.
>See 
>https://wiki.sagemath.org/ReleaseTours/sage-9.4#Alternative_installation_methods_using_pip
>
>It's documented in our README: 
>https://github.com/sagemath/sage/blob/develop/README.md#alternative-installation-using-pypi
>
>However, installing Sage in this way is equivalent to installing the full 
>Sage distribution from source in the normal way.

No, it is not equivalent, far from it. One can read on


 Building sagemath-standard has a large number ofsystem packages as 
prerequisites. See 
https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation
 for partial lists for various systems.

That is, many packages are not built. What's being built is not a Sage 
distribution, it is sagelib.


> (This is 
>what https://pypi.org/project/sage-conf/ does.)
>It takes very long. This alone makes it simply not suitable as a dependency 
>of other pip-installable projects.
>
>
>In another message, you asked:
>> 1.) Is there an example for someone who did not want to use sage because 
>of some dependency of the math library?  Or at least a possible reason? 
>[...] But this begs the question: who profits from cutting the math library 
>into pieces (which look very arbitrary to me and have a curious emphasis on 
>discrete math topics)?
>
>If you do allow me another example from discrete math: Sage has a lot of 
>very good code in "sage.graphs" that provides functionality that is not 
>available from other Python libraries. 
>
>But to potential projects that would need this functionality, the 
>proposition to have to depend on the monolithic project SageMath, with 
>hours of compilation time and/or dependencies on system packages that are 
>obviously unrelated to the needed functionality (boost, brial, ecl, eclib, 
>ecm, fflas_ffpack, flint, libgd, gap, giac, givaro, glpk, gmp, gsl, iml, 
>lcalc, libbraiding, libhomfly, libpng, linbox, m4ri, m4rie, mpc, mpfi, 
>mpfr, ntl, pari, rw, singular, symmetrica), is simply a showstopper.
>

This is not true, either. First, a lot of these packages that you list are 
available on systems, and thus there is no need to build them.
(To "but macOS?" I have a reply: "ask Apple to provide you a package manager, 
it's the best OS, right, you pay for it a lot of money, or learn to use 
Homebrew like  Mac users usually do...")

Anyway, a normal Python pypi-installable package comes with binary wheels, i e. 
things are pre-built, and it's merely matter of downloading these to get a 
functional package. Few minutes on a fast network, not hours.
By choosing to be an exception in the Python world,
Sage obviously does something quite wrong.

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/2D37D4FE-4FBC-4F65-8E7E-27B036B2E4C1%40gmail.com.

Re: [sage-devel] Re: SingularError in rational_parameterization

[Dima Pasechnik]

I've filed https://github.com/sagemath/sage/issues/37838

On Sat, Apr 20, 2024 at 5:34 PM Dima Pasechnik  wrote:

> This is due to https://github.com/sagemath/sage/pull/37495
> Sorry, this is the  usual careless reviewing of late, preventing people
> from using their own Singular (too "new")
> The check should have been conditional on building Sage's own Singular -
> otherwise it should have been ignored.
>
> You can revert the this PR, and re-run ./bootstrap
>
> On Saturday, April 20, 2024 at 5:10:41 PM UTC+1 Peter Mueller wrote:
>
>> Dima Pasechnik schrieb am Samstag, 20. April 2024 um 17:57:05 UTC+2:
>>
>> [...] well, this looks relevant.  "any of gmp ntl flint readline mpfr
>> cddlib is installed as or will be installed as SPKG"
>>
>> these are Singular's dependencies, and possibly not all of them are on
>> your OS.
>> In particular, flint is not there - you need Flint 3, and it's only in
>> the very latest Ubuntu, cf.
>> https://packages.ubuntu.com/search?searchon=sourcenames=flint
>>
>> You might want to install latest flint3, 3.1.2, into /usr/local/, and
>> try again.
>> This will be dodgy, and not really very good idea,
>> as your Singular is built with flint2,  I suppose...
>>
>>
>> well, all these packages were installed when I compiled sage:
>>
>> `pacman -Q gmp ntl flint readline mpfr cddlib` returns
>>
>> gmp 6.3.0-1
>> ntl 11.5.1-1
>> flint 3.1.2-1
>> readline 8.2.010-1
>> mpfr 4.2.1-2
>> cddlib 1:0.94m-1
>>
>> -- Peter
>>
> --
> 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/0e3b2cae-6a6c-45b6-af2d-d35118d044d1n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/0e3b2cae-6a6c-45b6-af2d-d35118d044d1n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAAWYfq0hfzMDhN4_MUzKLfhXAjNJ%3DxsLdK2Mpeoo0pjiAaooww%40mail.gmail.com.

Re: [sage-devel] Re: SingularError in rational_parameterization

[Dima Pasechnik]

This is due to https://github.com/sagemath/sage/pull/37495
Sorry, this is the  usual careless reviewing of late, preventing people 
from using their own Singular (too "new")
The check should have been conditional on building Sage's own Singular - 
otherwise it should have been ignored.

You can revert the this PR, and re-run ./bootstrap

On Saturday, April 20, 2024 at 5:10:41 PM UTC+1 Peter Mueller wrote:

> Dima Pasechnik schrieb am Samstag, 20. April 2024 um 17:57:05 UTC+2:
>
> [...] well, this looks relevant.  "any of gmp ntl flint readline mpfr 
> cddlib is installed as or will be installed as SPKG"
>
> these are Singular's dependencies, and possibly not all of them are on 
> your OS.
> In particular, flint is not there - you need Flint 3, and it's only in the 
> very latest Ubuntu, cf.
> https://packages.ubuntu.com/search?searchon=sourcenames=flint
>
> You might want to install latest flint3, 3.1.2, into /usr/local/, and
> try again.
> This will be dodgy, and not really very good idea,
> as your Singular is built with flint2,  I suppose...
>
>
> well, all these packages were installed when I compiled sage: 
>
> `pacman -Q gmp ntl flint readline mpfr cddlib` returns
>
> gmp 6.3.0-1
> ntl 11.5.1-1
> flint 3.1.2-1
> readline 8.2.010-1
> mpfr 4.2.1-2
> cddlib 1:0.94m-1
>
> -- Peter
>

-- 
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/0e3b2cae-6a6c-45b6-af2d-d35118d044d1n%40googlegroups.com.

Re: [sage-devel] Re: SingularError in rational_parameterization

[Dima Pasechnik]

On Friday, April 19, 2024 at 12:36:26 PM UTC+1 Peter Mueller wrote:

@Dima, thanks, I know that though. Nevertheless, I now started from anew 
(that is I removed the sage directory and git-cloned sage to make sure that 
there are no remains causing trouble). After running configure, the script 
suggests to `sudo pacman -S eclib fflas-ffpack linbox nauty singular`. 


these suggestions are often bogus (and it's the case here). There is not 
check done on whether these are actually installed - it's only checking
whether such a package is available for your OS, but not going to be used 
by Sage.
 

However, all these packages are installed: `pacman -Q eclib fflas-ffpack 
linbox nauty singular` returns
eclib 20240408-1
fflas-ffpack 2.5.0-1
linbox 1.7.0-1
nauty 1:2.8.8-2
singular 4.3.2.p16-1

The possibly relevant snippets of the config.log are

[...]
It was created by Sage configure 10.4.beta3, which was
generated by GNU Autoconf 2.72.  Invocation command line was

  $ ./configure --enable-bliss --enable-cbc --enable-csdp --enable-dsdp 
--enable-gap_p
ackages --enable-libnauty --enable-mcqd --enable-msolve 
--enable-pari_galpol --enable-
scip --enable-scip_sdp --no-create --no-recursion
[...]
hostname = wma7117
uname -m = x86_64
uname -r = 6.8.5-arch1-1
uname -s = Linux
uname -v = #1 SMP PREEMPT_DYNAMIC Thu, 11 Apr 2024 01:47:33 +

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/mueller/.codon/bin/
PATH: /home/mueller/.codon/bin/
PATH: /home/mueller/local/copt/bin/
PATH: /usr/local/sbin/
PATH: /usr/local/bin/
PATH: /usr/bin/
PATH: /usr/bin/site_perl/
PATH: /usr/bin/vendor_perl/
PATH: /usr/bin/core_perl/
PATH: /home/mueller/local/bin/
PATH: /home/mueller/Adm/local/bin/
PATH: /home/mueller/local/gurobi/linux64/bin/

and

## Checking whether SageMath should install SPKG singular... ##
## - ##
configure:49864: checking whether any of gmp ntl flint readline mpfr cddlib 
is installed as or will be installed as SPKG
configure:49869: result: yes; install singular as well
configure:50085: no suitable system package found for SPKG singular


well, this looks relevant.  "any of gmp ntl flint readline mpfr cddlib is 
installed as or will be installed as SPKG"
these are Singular's dependencies, and possibly not all of them are on your 
OS.
In particular, flint is not there - you need Flint 3, and it's only in the 
very latest Ubuntu, cf.
https://packages.ubuntu.com/search?searchon=sourcenames=flint

You might want to install latest flint3, 3.1.2, into /usr/local/, and
try again.
This will be dodgy, and not really very good idea,
as your Singular is built with flint2,  I suppose...

Dima




dim...@gmail.com schrieb am Freitag, 19. April 2024 um 12:08:01 UTC+2:

On Fri, Apr 19, 2024 at 02:28:13AM -0700, 'Peter Mueller' via sage-devel 
wrote: 
> I just figured out that the installation from source (even with the 
> explicit configure option `--with-system-singular`) on an up to date arch 
> linux machine ignores the installed singular (`pacman -Q singular` 
returns 
> `singular 4.3.2.p16-1`). Not sure if it is a path problem that makes the 
> configure script fail to detect the singular installation. 
The 1st thing 1st, 
if your source install already has singular built, you need to uninstall 
it, for ./configure to pick up the system-wide one. 

if you post your config.log we can tell you more on why it goes wrong. 

Dima 

> 
> Antonio Rojas schrieb am Donnerstag, 18. April 2024 um 09:03:22 UTC+2: 
> 
> Works fine with system singular 4.3.2.p16 too, so this may be a bug in 
that 
> particular Singular version. 
> 
> El jueves, 18 de abril de 2024 a las 6:02:53 UTC+2, Kwankyu Lee escribió: 
> 
> No problem with Singular 4.3.2 included in sage (on mac). 
> 
> -- 
> 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+...@googlegroups.com. 
> To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a671ea8e-e0c5-4dbe-9510-5139c9bb24ffn%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/94d92418-763e-476c-9feb-24ea4863d402n%40googlegroups.com.

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

[Dima Pasechnik]

Hi Volker,

On Sat, Apr 20, 2024 at 10:22 AM Volker Braun  wrote:

> Yes in a perfect world, but then you don't get a gold star for satisfying
> some purity test. We should just do the minimal amount of work to get us
> where we want to be. Lets focus on the direction to go and not too much on
> the process.
>


the keywords are "where we want to be" and "direction".
The revert should happen as there is no agreement on this.

It would help if we first sort out and agree on these, then we can resume
the normal operations.

IMHO it would help if you stopped touching these disputed PRs until this
these are done, or at least for a set period of time,
say a month or two.

Dima



>
> On Friday, April 19, 2024 at 7:18:03 PM UTC+2 Michael Orlitzky wrote:
>
>> On Fri, 2024-04-19 at 09:46 -0700, Matthias Koeppe wrote:
>> >
>> > Michael, note that in my message I asked for a vote on that dependency
>> > https://github.com/sagemath/sage/pull/36676.
>> >
>>
>> Even if 36676 gets approval, 36964 must be reverted. It was not
>> meaningfully voted upon.
>>
>> --
> 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/b9d41da8-57ec-4542-a5d8-7f2690849a49n%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/CAAWYfq3iAWpJQpMFzcF09-FnNgzMXnsExzpUti-YAZ%2BrhCNqDQ%40mail.gmail.com.

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

[Dima Pasechnik]

On 20 April 2024 08:56:30 BST, 'Martin R' via sage-devel 
 wrote:
>A follow-up question: do I understand correctly that common lisp (via 
>maxima) is the main dependency that prevents sagemath from being 
>pip-installable?

pip install sagemath-standard

already works in a venv on a box with enough deps
installed. Takes lot of time. To fix this,
anyhow, someone has to make their hands dirty and do to Lisp interface what's 
done to Pari/GP (cypari)
PPL (pplpy), primecount (primecountpy), etc.
Apart from Lisp, there is GAP (with the corresponding effort stalled).

That's what is much more urgent than attempting to slice up the maths 
functionality of sagelib.

Dima
>
>All the best,
>
>Martin
>On Friday 19 April 2024 at 21:34:06 UTC+2 Martin R wrote:
>
>> On Friday 19 April 2024 at 20:08:51 UTC+2 Matthias Koeppe wrote:
>>
>> On Friday, April 19, 2024 at 5:08:02 AM UTC-7 Martin R wrote:
>>
>> 2.) If this is about dependencies on other software, why aren't the 
>> distributions named after these dependencies?
>>
>>
>> Martin, I have answered this already when you asked it in the PR: Some are.
>>
>>
>> Matthias, this does not answer my question.  Maybe it is clearer if I ask: 
>> why do you introduce distributions sage-graphs, sage-combinat, 
>> sage-categories etc.
>>
>> Martin
>>
>>  
>>
>> Note that the description of the PR where you asked this question contains 
>> the list of the distributions: https://github.com/sagemath/sage/pull/36676
>> "We restructure the all.py files for modularization. Guided by the 
>> technical constraints outlined in 
>> https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s, 
>> https://github.com/sagemath/sage/pull/35095 defines distribution packages 
>> (pip-installable packages) sagemath-{brial, combinat, eclib, flint, gap, 
>> giac, glpk, graphs, groups, homfly, lcalc, libbraiding, libecm, linbox, 
>> modules, mpmath, ntl, pari, plot, polyhedra, schemes, singular, 
>> standard-no-symbolics, symbolics}."
>>
>> My June 2023 sage-devel post 
>> https://groups.google.com/g/sage-devel/c/kiB32zP3xD4 explained that the 
>> design use "... 3 types of distribution packages:
>> - Packages that are named after a basic mathematical structure but may 
>> cover a wide range of generalizations/applications of this structure.
>> - Packages that are named after an upstream library. 
>> - Packages that are named after a technical functionality."
>>
>>
>

-- 
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/7F679D01-A0C0-482E-BFEA-68ABC1FC7C81%40gmail.com.

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

[Dima Pasechnik]

Another attempt at derailing the ongoing vote, not unexpected.

Besides, Matthias must be really the greatest democrat of all - 1st he blocks a 
part of electorate from voting at the designated venue, and then invite 
everyone to vote there.

I urge everyone to ignore this alternative vote - to protest against this 
offensive behaviour.

Dima

On 18 April 2024 22:18:37 BST, Matthias Koeppe  wrote:
>Dear all:
>
>As an alternative to the proposal to back out the 
>PR https://github.com/sagemath/sage/pull/36964 whose *disputed dependency 
>PR https://github.com/sagemath/sage/pull/36676 which had not reached the 
>required 2:1 supermajority *of the dispute-resolution process *(it 
>currently only has a simple majority of 7 votes in favor, 5 votes against)* 
>--- I am asking for your votes on that dependency PR 
>https://github.com/sagemath/sage/pull/36676 to heal the process. This will 
>avoid further delays and disruptions.
>
>*What is the modularization project?* The Sage developer community has long 
>been aware of the severe problems that the monolithic design of Sage has 
>brought. See in particular the lively 2016 sage-devel thread "How we 
>develop Sage" (https://groups.google.com/g/ sage-devel/c/29ndCD8z94k) 
>initiated by William. In its current incarnation, "modularization project" 
>refers to my proposal from May 2020,
>- to use modern Python packaging ("PEP 517/518/660") and Python 3's 
>"implicit namespace packages" to 
>- break the Sage library into separately buildable and installable 
>"distribution packages"
>- while keeping the structure of the source tree mostly unchanged, 
>monolithic, for the convenience of the Sage developer community.
>For the project, hundreds of tickets/PRs have been prepared and merged over 
>the past 4 years, see the Meta-ticket 
>https://github.com/sagemath/sage/issues/29705 for a list.
>
>*Has the Sage community been informed and consulted regarding the 
>modularization project? *Yes, in addition to the normal review that all 
>tickets/PRs underwent:
>- I have given detailed presentations about the project in SageDays 110 
>(2020), 112.358 (2022), 120 (2023), 
>see https://github.com/sagemath/sage/issues/29705 for links.
>- A chapter of the Sage Developer Guide, 
>https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#packaging-the-sage-library,
> 
>provides a detailed description of the design
>- I have posted numerous times to sage-devel, most recently the series 
>"SageMath modularization project: The five by five" (2023-06). See 
>https://github.com/sagemath/sage/issues/29705 for links to all of these.
>- Specifically, in the post "Modularization project: V. The blocs" 
>(https://groups.google.com/g/sage-devel/c/kiB32zP3xD4/m/GJ0qF7TTAAAJ, 
>2023-06), I outlined the design of the pip-installable packages such as 
>sagemath-combinat, sagemath-graphs, sagemath-flint, sagemath-plot etc. 
>- And in my 2023-11 post 
>https://groups.google.com/g/sage-devel/c/kiB32zP3xD4/m/GJ0qF7TTAAAJ in the 
>same thread, I asked: 
>> Ready for review: A restructuring of our "all.py" files along these 
>dependencies in https://github.com/sagemath/sage/pull/36676. This is an 
>opportunity to review the contents of the proposed distributions 
>implemented in Mega-PR https://github.com/sagemath/sage/pull/35095 (~50 
>kLOC changes, not open for review). As 
>https://github.com/sagemath/sage/pull/36676 rewrites all "all.py" files, it 
>is also an opportunity for a deliberate coding style decision for these 
>files. I welcome all constructive discussions in the PR.
>
>*What does the PR https://github.com/sagemath/sage/pull/36676 do? *Per its 
>title, "Restructure sage.*.all for modularization, replace relative by 
>absolute imports". The PR is "mostly harmless": There are no user-visible 
>changes; it's just a bunch of imports that are moved around. It includes no 
>policy change of any kind; it only executes a design that was previously 
>reviewed and carefully documented in separate PRs. Nothing permanent or 
>irreversible is done here. The new files provide the top-level namespaces 
>needed for doctesting modularized installations of Sage.
>
>*Has it been reviewed?* Yes, David Coudert and John Palmieri did a detailed 
>review. This was completed on November 15, 2023 --- over 5 months ago.
>
>*How did this PR become "disputed"?* Back in November, one commenter 
>floated an (untested) alternative design 
>(https://github.com/sagemath/sage/pull/36676#pullrequestreview-1726079717); 
>I explained 
>in https://github.com/sagemath/sage/pull/36676#issuecomment-1806873154 why 
>it's not suitable. Commenter demanded that the previously reviewed and 
>documented design is reopened for discussion, 
>https://github.com/sagemath/sage/pull/36676#issuecomment-1863667919. 
>
>*What are the concerns that have been made known during the voting process 
>for this PR (March/April 2024)?* I will not attempt to paraphrase, but here 
>are links to some posts so that you can find the 

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

[Dima Pasechnik]

+1 to reverting the wrong merge

On 18 April 2024 16:54:08 BST, 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
> by
>John Palmieri on November 15, and then disputed.  The most recent count was 6-4
>in favor
>
>(falling short of the 2-1 ratio needed under the disputed voting process);
>since then I voted
> in
>favor, it was included in the merge of #36964
>, and then Martin voted
>against.
>
>
>At issue is the PR #36676 ,
>where discussion was still ongoing when #36964
> was merged.  The reversion of
>this PR proposed is purely for process reasons (I voted in favor of #36676
> before all this happened!).
>The 5 Sage developers opposed to #36676
> deserve to have our processes
>followed.  What went wrong?
>
>I think what happened resulted from a combination of the new disputed
>voting process, mismatched expectations around dependencies after the move
>to github, and Volker's release management scripts.  Several developers
>privately expressed concern prior to this merge about exactly this outcome,
>and I reassured them that dependencies would be taken into account.
>Unfortunately, dependencies are now (unlike in trac) just a text section of
>the PR comment, and the release scripts only see the label.
>
>
>There are lots of things to discuss around this chain of events.  I ask
>that everyone keep this thread focused on whether to merge #37796
> in order to revert #36964
>.  Some other topics, and
>places I 

[sage-devel] Urgent proposal: stop merging PRs without consensus, work on a way forward

[Dima Pasechnik]

We urgently need to recover some degree of sanity in how the contributions are 
merged.

The proposal is to halt the current trend of political PR reviews, namely only 
merge PRs where there is a consensus.

This is getting particularly urgent in view of few still disputed PRs being 
merged, and pushback against these merges being reverted.

Please discuss, I'll call a vote in, say, 24 hours.

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/BB0BC992-C775-4AC4-BCA3-279E6C82641C%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 10:01 PM François Bissey 
wrote:

>
>
> On 16/04/24 04:41, kcrisman wrote:
> > SageMath has several other long-term contributors who also package
> > software. We're all roughly on the same page about what it would take
> > to fix the sage installation for end users.
> >
> >
> > And some of these people (perhaps kiwifb?) have not been as directly
> > involved in some of the recent disputes.   Maybe there is a path forward
> > (I also presume the CoCC is thinking about this).
>
> I would say I have involved myself too much already. I am regularly
> asked to review some of those tickets that are disputed or become disputed.
>
> It floods my inbox and makes my heart sink.
>

Well, on the latest disputed PR https://github.com/sagemath/sage/pull/37796
I proposed
to stop with this all and go back to getting the PRs approved by consensus.

Should we call an urgent general vote on this?

Dima



> François
>
> --
> 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/d7dd2f74-8c1a-4e9a-be42-5b4816065e30%40gmail.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/CAAWYfq0r4vFeD36jhVEBYhxGWebcCZ2_9iKc1J8tdoyJzRBAQw%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 15 April 2024 22:13:59 BST, John H Palmieri  wrote:
>+1 to the inclusion of the package, in case anyone views the voting as 
>still open.
>
>François, thank you for letting us know about how the ongoing disputes are 
>affecting you. I feel your pain.

John, do you think Francois is the only one? I oscillate between quitting the 
project, making a fork, continuing this endless voting fight, etc. - instead of 
doing more useful things.

I propose to go back to merging PRs etc by consensus, while we figure out a 
compromise.

Dima

>
>Regards,
>  John
>
>
>On Monday, April 15, 2024 at 2:01:43 PM UTC-7 François Bissey wrote:
>
>>
>>
>> On 16/04/24 04:41, kcrisman wrote:
>> > SageMath has several other long-term contributors who also package
>> > software. We're all roughly on the same page about what it would take
>> > to fix the sage installation for end users.
>> > 
>> > 
>> > And some of these people (perhaps kiwifb?) have not been as directly 
>> > involved in some of the recent disputes.   Maybe there is a path forward 
>> > (I also presume the CoCC is thinking about this).
>>
>> I would say I have involved myself too much already. I am regularly 
>> asked to review some of those tickets that are disputed or become disputed.
>>
>> It floods my inbox and makes my heart sink.
>>
>> François
>>
>

-- 
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/B9B7E1DE-1150-4773-8091-2591A4CC0AB5%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman  wrote:

>
> We (not just Sage, but you and I!) have been discussing this for
> almost 15 years.
>
>
> Haha, true!
>
>
> SageMath has several other long-term contributors who also package
> software. We're all roughly on the same page about what it would take
> to fix the sage installation for end users.
>
>
> And some of these people (perhaps kiwifb?) have not been as directly
> involved in some of the recent disputes.   Maybe there is a path forward (I
> also presume the CoCC is thinking about this).
>
>
> But so far, every attempt to disentangle the
> library/distribution to enable this division of labor has been met
> with resistance by essentially one person.
>
>
> Well, more accurately there must be a critical mass of people who, like
> Kwankyu in some recent comments (apologies for not having link to hand),
> want to trust that the related process undertaken by that person is worth
> doing, and to let that proceed.  Otherwise they would have spoken up, as
> many longer-term developers are not shy of doing so on other matters.
>
> Regarding WSL in Dima's post, I thought
> https://github.com/sagemath/sage/pull/37184 (and the followups) addressed
> this quite a bit - that was what I was referring to.  If I could get it to
> work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not
> included in it.  Anyway, I was definitely not referring to anyone who knows
> what "apt-get" is in WSL.  So am I right in your saying that Jupyter
> wouldn't work "out of the box" with Sage with the conda-based solution for
> WSL?  To me, that's an argument *for* batteries, not against.
>
> Same applies for the MacOS version provided by 3manifolds, my assumption
> was that this would work "out of the box" if you do sage -n jupyter or
> something.  That assumption could be wrong - but again, why put additional
> barriers to the user?  "Normal" software that "normal" i.e. non-developer
> people use in the real world doesn't do that.  Why make that a prerequisite
> for just doing math?  I hate to beat the dead horse of the now-debatable
> mission statement, but does Mathematica make you separately download and
> install a notebook?
>

scipy does,
sympy does,
Macaulay2 does,
GAP does,
R does,
Julia does...





>   Even LaTeX has this problem - you have to install the distribution
> separately from TeXShop or what have you - and just like the developer
> friction noted here, it's a little bit of extra friction.
>
> > What fragmentation are you talking about?
>
> I meant that it's a bit silly (from the Mac or Windows perspective) that
> one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else on
> the massive (and probably incorrect) list on Wikipedia:
> https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a
> massive duplication of effort right there.
>
> > It has to be formulated and agreed upon in general lines, otherwise such
> a summit would be a waste of time.
>
> Agreed.  All of my points are irrelevant compared to getting us back on
> some consensus track.  That means toning down the rhetoric and candidly
> saying what sub-optimal concessions might be on the table (to be clear, for
> everyone).  It's clear now that at least two visions for Sage
> packaging/modularization which, in their current technical state, are
> viewed by stakeholders as colliding in their purest forms, but it seems
> unlikely that Sage is not Turing-complete enough to support a modus vivendi.
>
> --
> 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/7ebdcd4a-b8fa-4e1a-8f65-687730fa309bn%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/CAAWYfq2ge95V2XtFFtM3gsgyZsgUDZBb0sg%3DcLq%3DRSkqZwj_hg%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman  wrote:

>
> We (not just Sage, but you and I!) have been discussing this for
> almost 15 years.
>
>
> Haha, true!
>
>
> SageMath has several other long-term contributors who also package
> software. We're all roughly on the same page about what it would take
> to fix the sage installation for end users.
>
>
> And some of these people (perhaps kiwifb?) have not been as directly
> involved in some of the recent disputes.   Maybe there is a path forward (I
> also presume the CoCC is thinking about this).
>

kiwifb has a custom-made Sage on a mini-distro (a Gentoo prefix) which
mostly works for him - and he's too busy anyway, I suppose.


>
>
> But so far, every attempt to disentangle the
> library/distribution to enable this division of labor has been met
> with resistance by essentially one person.
>
>
> Well, more accurately there must be a critical mass of people who, like
> Kwankyu in some recent comments (apologies for not having link to hand),
> want to trust that the related process undertaken by that person is worth
> doing, and to let that proceed.  Otherwise they would have spoken up, as
> many longer-term developers are not shy of doing so on other matters.
>

Kwankyu has been very open in saying that he does political voting.
I presume that's what applies to the rest of that "mass" you mention -
almost everyone there is a convicted serial macOS user.



> Regarding WSL in Dima's post, I thought
> https://github.com/sagemath/sage/pull/37184 (and the followups) addressed
> this quite a bit - that was what I was referring to.  If I could get it to
> work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not
> included in it.  Anyway, I was definitely not referring to anyone who knows
> what "apt-get" is in WSL.  So am I right in your saying that Jupyter
> wouldn't work "out of the box" with Sage with the conda-based solution for
> WSL?  To me, that's an argument *for* batteries, not against.
>

No, no amount of "batteries" will help you here - you need your Jupyter to
be run on the Windows side, not on WSL side, so that you can use either a
Windows browser or (Windows-side) VS Code to run Jupyter.

What would really simplify things here is creation of a Windows based
installer, not mere a document
on dozens of things to be done to set it all up.

As to whether it would work with Conda-based Sage in WSL - I don't know,
the crucial thing here is automatic discovery of Sage's Jupyter kernel (a
small JSON file)

>
> Same applies for the MacOS version provided by 3manifolds, my assumption
> was that this would work "out of the box" if you do sage -n jupyter or
> something.
>

3manifolds app packages a completely separate full-blown Jupyter
installation
to interact with Sage (with their standard launcher), and that's the only
Jupyter they support.
They don't need to package "batteries" which are just ballast for their app.

 That assumption could be wrong - but again, why put additional barriers to
> the user?  "Normal" software that "normal" i.e. non-developer people use in
> the real world doesn't do that.  Why make that a prerequisite for just
> doing math?  I hate to beat the dead horse of the now-debatable mission
> statement, but does Mathematica make you separately download and install a
> notebook?   Even LaTeX has this problem - you have to install the
> distribution separately from TeXShop or what have you - and just like the
> developer friction noted here, it's a little bit of extra friction.
>
> > What fragmentation are you talking about?
>
> I meant that it's a bit silly (from the Mac or Windows perspective) that
> one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else
>

Mac? I am not familiar with any medium/large size business which uses macOS
on anything apart from desk/laptop.

Windows? WSL didn't arise from nothing...

(sorry if I failed to notice irony here)

on the massive (and probably incorrect) list on Wikipedia:
> https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a
> massive duplication of effort right there.
>

Cf.
https://en.wikipedia.org/wiki/List_of_the_largest_Protestant_denominations
(and that's "protestant"+"largest" only)


> > It has to be formulated and agreed upon in general lines, otherwise such
> a summit would be a waste of time.
>
> Agreed.  All of my points are irrelevant compared to getting us back on
> some consensus track.  That means toning down the rhetoric and candidly
> saying what sub-optimal concessions might be on the table (to be clear, for
> everyone).  It's clear now that at least two visions for Sage
> packaging/modularization which, in their current technical state, are
> viewed by stakeholders as colliding in their purest forms, but it seems
> unlikely that Sage is not Turing-complete enough to support a modus vivendi.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and 

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 12:21 PM kcrisman  wrote:

>
> I understand that some macOS users are very comfortable with Sage the
> distro playing the role of a missing macOS package manager,
>
>
> The real question is about *users* in this case, not developers. I just
> got messed up the other day brew updating something which killed my Python
> 3.9 I need in order to use a specific package (nothing to do with Sage,
> completely orthogonal) for a certain course, a package which doesn't
> support the most recent Pythons yet, and frankly my teaching load (unlike
> perhaps that of most Sage developers, I acknowledge) doesn't leave time to
> learn the intricacies of pyenv or whatever there is out there to rectify
> such situations (I don't *mind* having 3.12 on my box ...).  Sage's
> "batteries included" means all my Sage installations of various vintages
> stay sandboxed, essentially, and that is pretty comforting.
>

Pyenv is easier than sage distro, much easier.
If there was an easy way to install Sage into a pyenv environment,
one could have used it...


> My guess is that most Sage *users* are in this kind of situation.
>

Well, depending on a legacy (3.9) Python version isn't the problem for the
most, I hope. :-)


>  The WSL solution using some version of conda now might allow something
> similar (?) for the VAST number of Windows users out there.
>

Combining WSL+conda might be a bit too sophisticated for - e.g. I'm not
sure it plays well with
using VS Code to run notebooks in WSL.
Thus, one probably would do in WSL "sudo apt-get install sage-jupyter",
installing Sage 9.5 - if the standard for WSL Ubuntu 22 is used). This is
old Sage...
Yes, one can follow the advice in
https://sagemanifolds.obspm.fr/install_ubuntu.html
to get an up to date Sage in your Ubuntu WSL.

One way or another, this involves packaging Sage for Ubuntu (current;y
stalled), or for Conda (something that suffers from the same issues as
other distro packaging)


>  CoCalc probably provides a single solution to a large number of users too
> (how large, I don't know) for people using Mac and Windows in their
> day-to-day work, who don't mind a little Terminal to get some math done but
> don't want to use Linux (among other reasons, because many of us can't
> afford our own personal computers for work, so we have to take the options
> work gives us, which is emphatically not Linux).  It's great that the
> fairly small number of Linux users wordwide have the package manager
> concept,
>
the VAST number of Windows (+WSL) users have the package manager concept
(in their WSL), too.
They all most probably do "sudo apt-get install sage-jupyter" if they want
to run Sage.



> but its very fragmentation (!!!) surely takes a lot of developer time too
> (not just for Sage) as well.  So this argument, by itself, isn't sufficient.
>

What fragmentation are you talking about?
Packaging even a relatively sophisticated CAS like GAP for an OS isn't a
particularly hard task.
Once done, updates aren't time consuming at all.
SageMath should be easier than GAP to package, and not much harder.
And it's much harder at present, as it stubbornly refuses to be a good
member of Python universe.


>
> but it makes me sad that I spent many months of my time debugging and
> improving Sage on macOS, and getting this kind of cold shoulder in response
> to my requests.
>
>
> This is totally legitimate, as I've said before, and is the real crux of
> the issue.  I would hope people who don't want "batteries included" could
> live with it if there weren't a lot of unseen maintenance.
>

Mind you, even macOS users of Sage, who use the 3-manifold app
from https://github.com/3-manifolds/Sage_macOS/releases (as recommended on
https://doc.sagemath.org/html/en/installation/#macos), so it's probably the
macOS majority,
don't use most of the "batteries". E.g. they don't use packaged Jupyter.
And the VAST number of Windows+WSL users don't use packaged Jupyter.
(and they don't use Python build tools, or sphinx, or packaged compilers...)


 Under past circumstances, there would have been a Sage Days of some kind
> by now (in person) to hash out how to resolve the situation *with an
> acceptable consensus*, even if still imperfect, which lightens the load
> significantly on Linux package managers while keeping the other progress
> made on track.  We need something approximating this sort of summit now to
> resolve these issues - and I certainly do think there is an acceptable
> solution out there.
>

It has to be formulated and agreed upon in general lines, otherwise such a
summit would be a waste of time.

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 

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 14 April 2024 19:14:51 BST, Matthias Koeppe  wrote:
>When I completed the NumFOCUS application yesterday, I had to go through 
>the past years of sage-devel posts to answer the new question "Where do you 
>host conversations about project development and governance (e.g. mailing 
>lists, forums, etc.), and how many participants do you have?" (see 
>https://github.com/sagemath/sage/wiki/NumFOCUS#q16-where-do-you-host-conversations-about-project-development-and-governance-eg-mailing-lists-forums-etc-and-how-many-participants-do-you-have)
>
>While doing so, I also collected the sage-devel threads in which packages 
>were proposed to be added as standard packages, following our project's 
>procedures:


This is not an answer. I would like an explanation why Sage the distro has to 
grow the bloat at ever increasing speed, why you think it is sustainable, but, 
most of all, why "batteries included" is meaningful in 2024, and why these 
procedures must stay as they are.

I understand that some macOS users are very comfortable with Sage the distro 
playing the role of a missing macOS package manager, but it makes me sad that   
I spent many months of my time debugging and improving Sage on macOS, and 
getting this kind of cold shoulder in response to my requests. 



Dima

>- "Add pplpy and gmpy2 as standard packages" 
>(https://groups.google.com/g/sage-devel/c/qoxVng1__0A/m/4HntWHp_AQAJ, 
>2018-02)
>- "Make giacpy_sage a standard package" 
>(https://groups.google.com/g/sage-devel/c/uYXGzG_py28/m/4SN5hts4FQAJ, 
>2020-02)
>- "Add tox as a standard package" 
>(https://groups.google.com/g/sage-devel/c/G5kMggTecA8/m/2aTZSt_AAwAJ, 
>2020-09)
>- "Making cmake a standard package" 
>(https://groups.google.com/g/sage-devel/c/Ccumny9Yioc/m/litCsb6gAwAJ, 
>2021-07)
>- "New standard package: GNU Info" 
>(https://groups.google.com/g/sage-devel/c/aIx8i-0MRo4/m/4WxL64JlBAAJ, 
>2021-07)
>- "Add more-itertools as a standard package" 
>(https://groups.google.com/g/sage-devel/c/Dq83PiiCAsU/m/43WX3JgjDgAJ, 
>2021-12) 
>- "Make Jupyterlab a standard package" 
>(https://groups.google.com/g/sage-devel/c/orUpb-YXIHk/m/d_zDX3xyDQAJ, 
>2022-03)
>- "Make Furo a standard package" 
>(https://groups.google.com/g/sage-devel/c/VTU_I-ecPlA/m/KMd9cMX9AQAJ, 
>2022-08) 
>- "Make ipympl a standard package" 
>(https://groups.google.com/g/sage-devel/c/fRufANUCNdY/m/RKhnlUYdAgAJ, 
>2023-09)
>
>Our project's procedures have not changed.
>

-- 
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/E6787E1A-38C9-4C92-A2EE-525BDD491631%40gmail.com.

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Dima Pasechnik]

On 12 April 2024 12:42:39 CEST, Georgi Guninski  wrote:
>On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik  wrote:
>>
>> This should be fixed by https://github.com/sagemath/sage/pull/37792
>> please review
>>
>
>I suspect reproducing is hard, since it depends on the time of pressing CTL-C.

Well,  in all my tries the crash happened in the same place, the place that now 
is no longer reachable.

And the reason for the crash was, AFAIU, due to calling a plain Python code 
(where Ctrl-C was caught) from a "noexcept" Cython code. That is, it's a crash 
due to inability to properly process Ctrl-C.

How many more similar places are left there in Cython code in Sage, I don't 
know.

Dima


>Also, lack a crash may be silent memory corruption.
>
>It is weird that the crash is not always.
>
>Do you fix the attached new testcase (no interaction required, may
>need changing some constants)?
>

-- 
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/C701D76E-A116-4D83-B427-24C305F51201%40gmail.com.

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Dima Pasechnik]

This should be fixed by https://github.com/sagemath/sage/pull/37792
please review

On Thursday, April 11, 2024 at 10:19:31 PM UTC+1 dim...@gmail.com wrote:

> On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote:
> > Are the non-crashing codepaths in consistent state?
> > SEGV is in general sign of memory corruption and it may lead to wrong
> > math results or possibly have security implications.
>
> Here is an attempt to fix it; it appears that the call to
> characteristic() which causes a crash is a leftover which can simply be
> removed.
> https://github.com/dimpase/sage/pull/6
> (not yet a PR to the Sage repo, just want to see results of tests)
>
> 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/8d176b7d-a826-4713-ac3a-2a19c1c75669n%40googlegroups.com.

Re: [sage-devel] Re: source code tarball?

[Dima Pasechnik]

to be fixed by https://github.com/sagemath/sage/pull/37791
Please review.

Dima

On Wednesday, April 10, 2024 at 5:19:56 PM UTC+1 John Cremona wrote:

> Thanks, that's the page I was expecting.
>
> I think it would be a good idea to have that linked more obviously, but  I 
> am not able to make a PR right now.
>
> I found a tarball on GitHub on the releases page, so made progress, though 
> as I reported elsewhere I have not yet been able to build sage from it on 
> one machine.
>
> John
>
>
>
> On Wed, 10 Apr 2024, 15:24 julian...@fsfe.org,  wrote:
>
>> I guess the idea is that further down on this page, you are told to 
>> follow the instructions in the README here 
>> https://github.com/sagemath/sage/#readme which in turn tells you get the 
>> "sources" from here https://www.sagemath.org/download-source.html.
>>
>> I agree that this is not terribly intuitive, however, the wikipedia link 
>> was introduced in
>>
>> commit 5cddc06a8118d8fb9211fe8232b1183daba9f01f
>> Date:   Tue Mar 29 15:11:07 2011 +0100
>>
>> So it's been there for quite a while but certainly the surroundings have 
>> been modified quite a bit since then.
>>
>> If you want to create a PR to change that link, I am happy to give it 
>> positive review.
>>
>> julian
>>
>> On Wednesday, April 10, 2024 at 11:56:23 AM UTC+3 John Cremona wrote:
>>
>>> In the first line of 
>>> https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
>>>  
>>> the words "source code" are a link to the wikipedia page for "source code", 
>>> which is not very helpful.  I was expecting it to be a link to page shoing 
>>> where to download a tarball.  I sometimes use the tarball to install from 
>>> source, instead of using a git clone -- I assume that has not been 
>>> discontinued?
>>>
>>> John
>>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/52db9220-62b4-4fc5-ac5a-f77bd040a9b7n%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/b52110d7-408b-40f6-8401-c526d0261d93n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 11 April 2024 21:47:57 CEST, Matthias Koeppe  
wrote:
>Once again, the workflow files in .github/workflows have to be statically 
>present in a repository so that Actions work.
>And the .devcontainers files have to be statically present in a repository 
>so that Codespaces work. 

Yes, sure, as I said, you can have it statically present, and test a submodule 
containing sagelib from there.

There is nothing hard to design here, once you split the repo this way.


>
>If you want to propose a design for breaking our repository into multiple 
>repositories, work it out first. Learn about the relevant technological 
>restrictions. 
>It does not make sense to develop it here in a question-and-answer game. 
>In particular, this cannot be done here in this thread about governance; 
>it's only a distraction.
>
>Matthias
>
>
>On Thursday, April 11, 2024 at 12:36:20 PM UTC-7 Dima Pasechnik wrote:
>
>On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
>wrote: 
>>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote: 
>> 
>>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>>> Necessary reminder that we're discussing, as the subject says, the files 
>>> that control the GitHub workflows and the Codespaces. 
>>> What a developer may do on their local machine does not matter. 
>> 
>>But there is no difference here between a CI and a local machine here. 
>>A CI is perfectly capable of doing 
>>"git submodule update --remote" 
>>and proceed. 
>> 
>> 
>>No. These files are processed by GitHub before any custom code can be run. 
>
>Are you saying that "git submodule..." cannot be triggered by 
>repository_dispatch hook? 
>So GH Actions cannot be triggered by a submodule update? 
>
>
>
>> 
>

-- 
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/A3395AC1-7AE8-436A-B1AE-B864F5E79BA8%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
wrote:
>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote:
>
>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>> Necessary reminder that we're discussing, as the subject says, the files 
>> that control the GitHub workflows and the Codespaces. 
>> What a developer may do on their local machine does not matter. 
>
>But there is no difference here between a CI and a local machine here. 
>A CI is perfectly capable of doing 
>"git submodule update --remote" 
>and proceed.
>
>
>No. These files are processed by GitHub before any custom code can be run.

Are you saying that "git submodule..." cannot be triggered by 
repository_dispatch hook?
So GH Actions cannot be triggered by a submodule update?



>

-- 
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/D6F9CBA3-4EF6-430C-A534-46B7514CD975%40gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:
>
> We have carefully reviewed [...]
>
> We therefore disagree with characterizing opposing opinions as “artificial
> friction”, “hostile demands”, or an “attempt to sabotage”.
> Such allegations will have no effect other than to antagonize the other
> party. This is not helpful in fostering constructive debate.
>
>
> Julian, please, that's highly inappropriate. I'm not characterizing
> opposing *opinions*.
>

Matthias, you keep characterizing my input into discussions as "persistent
abusive conduct", see e.g. your
https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139

I demand a public apology, and a lift of the block on GitHub.
Else Matthias should be banned from SageMath for a while, if not
permanently. Enough is enough.

Dima


> With this terminology I'm describing the modes of existing, persistent,
> non-constructive *actions* on these PRs by others.
>

> These are not "allegations"; what I am describing has been happening in
> plain sight, is fully documented, and has been reported to the sage-abuse
> and CoCC committees. As you know, some of these have already led to
> sanctions by the committees, while I am still waiting for acknowledgment
> (and clear actions) regarding numerous reported violations of our code of
> conduct (and reviewing code) by the current committee.
>
> I do understand that the new committee is still learning how to recognize
> and handle abuse; it's a complicated and challenging topic to master. In
> the meantime, as I have asked the committee in private already, more
> thoughtful restraint in issuing public reprimands is necessary.
>
> --
> 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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%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/CAAWYfq3kPjHk8-_b69xesUWXgB51bXH3stkrw1_A%2Bet6c6Pq0Q%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
> wrote:
>
> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>
>
> Have you ever worked with submodules?
>
>
> Yes, Dima, I have.
>
>
> There is simply no need to keep the .gitsubmodules -
> the only file in the main repo affected by "git submodule update --remote"
> -
> always synchronized, commit-wise, for everyone.
>
>
> There is. Without doing that, the changes made in the submodule won't take
> effect.
>
This is not true.

  git submodule update --remote

will pick up submodules changes just fine.
Read the docs?

-- 
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/CAAWYfq1niXYTBjvEgncLBxq9KyZEWdVBmSXRn6ab56OiX8s2AA%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>

Have you ever worked with submodules?

There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by "git submodule update --remote"
-
always synchronized, commit-wise, for everyone.
Yes, it's a bit annoying to have that pesky .gitsubmodules around, and I
can imagine that
git-subtree etc I mentioned are a better alternative.

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/CAAWYfq0JXHPBpq4oFOjsBiaPoDGfqFWZpjT5H0xKGZ7cjXbMxQ%40mail.gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On 10 April 2024 21:50:43 CEST, Matthias Koeppe  
wrote:
>On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:
>
>On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe  wrote:
>
> You will find the comments in these PRs instructive -- also as 
>illustration for a (long overdue) *discussion about governance and review 
>standards* in the Sage project.
>
>
>*1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 
><https://github.com/sagemath/sage/pull/36561> and 
>https://github.com/sagemath/sage/pull/37138 
><https://github.com/sagemath/sage/pull/37138>* ("Move metadata from 
>setup.cfg to pyproject.toml").
>These are trivial "chore" PRs. They update metadata of our pip-installable 
>packages "sage-conf" and "sagemath-standard" to the latest format.
>These straightforward and appropriately focused PRs have been held back by 
>months by *bundling the review of the PRs with unrelated issues.* I call 
>this "artificial friction"; see the discussion in the PRs. To help overcome 
>this artificial friction, please vote.
>
>
>This is not true - the friction is not artificial. It is due to legitimate 
>concerns of developers who are not interested in
>spending all of their time on ever growing "Sage the distribution", and/or 
>who see little merit in Matthias' sagelib modulalisation
>project, which uses Python features (most of all, namespace packages)
>not universally supported by a number of important tools, such as  Cython 
>and pytest.
>
>Please vote -1 on these two PRs (there are more similar PRs around). This 
>will force Matthias to reconsider his priorities [...]
>
>
>What Dima is describing here is exactly the inappropriate bundling that I 
>have called out.

There seems to be nothing else, short of a project fork, to make Matthias 
reconsider.


> It's a violation of our standards of review.

By calling out for a mass vote you have essentially asked for such a violation.

Otherwise the whole thing about designing PRs by massive voting is a massive 
waste of developers' time, as normal reviewing can be a time-consuming process, 
in particular if the PR concerns a not a very familiar topic.


>
>As majority voting on PRs is our current conflict resolution mechanism: 
>All, please vote.
>
So what exactly are you asking for? For reviews, or for massive violation of 
our reviewing standards?

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/062AA6C5-23E9-4CDC-A74D-D8FA8E1D606E%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>[...] git submodules [...]
>
>
>git submodules are included in a repository by specific commit sha of the 
>submodule repo.
>So whenever one has to make a change in the submodule repo, one also has to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR? 

>Hence this does not solve anything; it only adds more friction.

Anyway, there are alternatives like git-subrepo 
https://github.com/ingydotnet/git-subrepo
and git-subtree, which are said to be 
much more convenient (myself I only used git-submodule, so this is only what 
others say)
and don't suffer from these real or imaginary problems with git-submodule.

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/C9A68AC0-5474-4A85-9E5C-771CDF803176%40gmail.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 10 April 2024 20:23:10 CEST, Matthias Koeppe  
wrote:
>Dima, our project does not have such a policy of not adding standard normal 
>packages. This bundling with your political demand is inappropriate and not 
>welcome here.


Why is it unwelcome?
I explained under what condition I am OK with making this package standard. I 
could have just said NO without any explanation.

It is technical and not political. Political is your " not welcome" remark.



>
>On Wednesday, April 10, 2024 at 11:20:14 AM UTC-7 Dima Pasechnik wrote:
>
>> As in the previous attempt, I am OK with it becoming standard only if it 
>> remains a pip package, a no new "batteries are included".
>>
>> As a matter of fact, there is no point in keeping Python toolchain 
>> packages vendored. They can all be pip packages just as well.
>>
>>
>> On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
>> wrote:
>>
>>> We added python_build as an optional "pip" package (see 
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>>>  for 
>>> the terminology),
>>> - 
>>> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>>>  (added 
>>> in 2022).
>>>
>>> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
>>> making source distributions and wheels from a Python source tree. It has 
>>> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>>> bdist_wheel" directly. We already use it for building the modularized 
>>> distribution packages. Making it a standard package will allow us to 
>>> modernize the build infrastructure (front-end) for the Sage library in the 
>>> Sage distribution.
>>>
>>> I'm proposing to make it a standard package according to the procedures 
>>> in our developer guide. Per our policy, that's a "normal" package, so its 
>>> dependency pyproject_hooks will also be added. The PR is prepared in 
>>> https://github.com/sagemath/sage/pull/37300 
>>>
>>> This is a re-do of my proposal 
>>> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ 
>>> whose discussion was stalled by commenters bundling it with political 
>>> demands. 
>>>
>>>
>

-- 
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/7C5A20B7-533C-4E75-8DEC-AE985DFBBAA9%40gmail.com.

Re: [sage-devel] Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

As in the previous attempt, I am OK with it becoming standard only if it 
remains a pip package, a no new "batteries are included".

As a matter of fact, there is no point in keeping Python toolchain packages 
vendored. They can all be pip packages just as well.

On 10 April 2024 05:44:36 CEST, Matthias Koeppe  
wrote:
>We added python_build as an optional "pip" package (see 
>https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
> for 
>the terminology),
>- 
>https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
> (added 
>in 2022).
>
>"python_build" (a.k.a. pypa/build) is the current standard front-end for 
>making source distributions and wheels from a Python source tree. It has 
>replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
>bdist_wheel" directly. We already use it for building the modularized 
>distribution packages. Making it a standard package will allow us to 
>modernize the build infrastructure (front-end) for the Sage library in the 
>Sage distribution.
>
>I'm proposing to make it a standard package according to the procedures in 
>our developer guide. Per our policy, that's a "normal" package, so its 
>dependency pyproject_hooks will also be added. The PR is prepared 
>in https://github.com/sagemath/sage/pull/37300 
>
>This is a re-do of my proposal 
>https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose 
>discussion was stalled by commenters bundling it with political demands. 
>
>-- 
>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/e6b74134-7ed7-4da4-8b41-bebeef5c1f15n%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/4133C84E-1CC6-41FF-9AB8-CCB28BAECF64%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 03:39:00 CEST, Kwankyu Lee  wrote:
>How about redefining the meaning of "CI Fix" label:
>
>1. We designate a person to be the CI manager. 
>2. For PRs pertaining to the designated directories and files, we add "CI 
>Fix" label
>3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
>4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
>5. Hot fix PRs for breakage of CI also gets "CI Fix" label.

No, this has a big risk that such a manager will accidentally push non-CI bits, 
and obviously the discipline for not mixing CI and non-CI bits in one commit/PR 
will need to be manually managed.

This is why my proposal to split the repo is much better in this way. 

(One of the mottos of the political party I am forced to set up is "monorepos 
considered harmful", along with "batteries excluded" :-))




>
>?
>
>

-- 
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/2F5FD23C-680E-4FC5-8ECE-69BE08A3F3B0%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 02:04:48 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 4:20:56 PM UTC-7 Dima Pasechnik wrote:
>
>have a CI/sage-distro repo [...] with all that .github/ etc stuff needed 
>for CI, including a part of build/ - and checkout sagelib as a submodule.
>
>
>Also that does not work. Part of the .github/workflows is to run the CI on 
>the pull requests for the Sage library, and the .devcontainer is for making 
>GitHub Codespaces available on the pull requests for the Sage library.

Regarding CI, triggering a git update+CI run on an event in  another repo is 
done via a repository_dispatch hook. 
<https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch>

Indeed, it would be silly if one needed to pollute another repo with your CI 
workflow files.

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/B44D0BAB-7B85-4121-B34E-5851FE72880E%40gmail.com.

[sage-devel] Re: [sagemath/sage] Restructure `sage.*.all` for modularization, replace relative by absolute imports (PR #36676)

[Dima Pasechnik]

Please whoever is not blocked by the author of this PR, record my -1 vote on 
this.

Yes, this vote has a political element in it.
You want to play politics - let us play it.

Dima

On 10 April 2024 02:40:40 CEST, Tobias Diez  wrote:
>@tobiasdiez requested your review on: sagemath/sage#36676 Restructure 
>`sage.*.all` for modularization, replace relative by absolute imports.
>

-- 
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/FAF996E6-B6EE-411C-93AA-CD18394A3CFF%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 00:51:33 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>How about moving them out of the main Sage tree into separate repos, which 
>can be accessed from the main tree as git submodules?
>
>
>That does not work. 
>.github/workflows orchestrates what runs in the repo -- so it has to be in 
>the repo.
>.devcontainer declares what is offered for the repo in GitHub -- so it has 
>to be in the repo.

Then the other way around - have a CI/sage-distro repo (which can very well 
have relaxed policies) with all that .github/ etc stuff needed for CI, 
including a part of build/ - and checkout sagelib as a submodule.

The orchestration between the two repos looks doable. 


>

-- 
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/E50C6018-FE63-4F0F-8938-231E7A492A91%40gmail.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

I think I will quit the Sage project as soon as decisions on technical merits 
of PRs and issues will start to be taken in a nakedly political way.

I am very strongly against any political overtones in  these matters - it 
reminds me all too well what's wrong is in academia in general.

Dima




On 9 April 2024 11:21:46 CEST, Kwankyu Lee  wrote:
>Hi,
>
>Reviewing a PR is a technical work, but voting on a disputed PR has a 
>political element. So I want to make a political remark concerning most of 
>the disputed PRs.
>
>The modularization project (making pip-installation packages that contain 
>portions of the sage library) started years ago with a general consensus of 
>the sage community. Matthias led the project and did most of hard works. 
>Many others did not care much about the project and still do not feel the 
>impact except when encountered with the (annoying) "# needs ..." tags.
>
>Matthias is also managing much of the sage build system and the CI (mostly 
>testing infrastructure) on github, partly to support the modularization 
>project. Many of us would appreciate that.
>
>Certainly Matthias is not an appointed dictator ruling the developers, but 
>I think we should at least acknowledge the leading role of him in the area 
>of his expertise. On technical discussions on PRs, we should give more 
>weight on his opinions from his expertise.
>
>I hope that you decide your vote by weighing the conflicting arguments on 
>the issues.
>
>Kwankyu
>
>-- 
>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/3b6b30f7-efea-4812-b5b7-0e1f5894f975n%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/01429D75-1154-433D-AC95-8B336A9FD754%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 9 April 2024 23:11:59 CEST, Matthias Koeppe  wrote:
>Dear Sage developers:
>I propose to consider the following governance change for a small part of 
>the Sage repository:
>1. The directories *.ci, .devcontainer, .github/workflows*. These are 
>special directories that control the GitHub workflows that run for example 
>on pull requests and when release tags are pushed.
>2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain 
>the infrastructure for portability testing of the Sage distribution 
>(https://doc.sagemath.org/html/en/developer/portability_testing.html). 
>
>Some of these files are shipped as part of the Sage distribution, but none 
>of them have any role in the build process or runtime of Sage, and thus 
>none of them are tested by the Release Manager.
>
>*Status quo: *All changes to these files go through the normal review 
>process for Sage PRs; when set to "positive review", Volker merges them 
>into the next development release.
>In the terminology of https://martinfowler.com/articles/ship-show-ask.html 
>(ht Gonzalo Tornaria), this is the "Ask" model.
>
>Acknowledgment: I'm grateful to all who have contributed to the review of 
>my PRs that made changes to these files in the past: thanks for your time 
>and energy.
>
>*Proposed change: *All changes to these files are made through PRs. When 
>the PR is ready, a developer in the Maintainer role directly merges the PR 
>into the "develop" branch.
>In other words, switch to the "Show" model for these changes.

How about moving them out of the main Sage tree into separate repos, which can 
be accessed from the main tree as git submodules?

Then they could be developed in a completely separate process, and the 
corresponding PRs and issues won't be clogging up the main repo (which is 
already overloaded with all sorts of tangentially relevant to sagelib things.)
And the governance of these parts will be a separate thing all together.


Dima

>
>*Why the change:*
>1. Changes to these files do not have any effect on the build and runtime 
>of Sage;
>- thus changes to these files do not risk breaking the mathematical 
>correctness, or the performance of anything in Sage;
>- hence there may not be the same need for formal review compared to 
>changes to the Sage library.
>
>2. Our project has a collective interest in smoothly operating development 
>infrastructure / quality assurance tools;
>- but tragedy of the commons;
>- more specifically, developing/improving such development tools only pays 
>off individually for developers with a sufficiently high volume of activity 
>(cf. 
>https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c);
>- there may also be a technical barrier that prevents developers from even 
>reviewing a PR that makes changes to these files;
>- hence, waiting for reviewers to approve a PR and waiting for the Release 
>Manager to merge it adds too much delay and friction.
>
>3. Examples (all PRs authored by me, waiting for review):
>- "CI build, doc-build: Run containers explicitly, separate jobs for 
>pyright, build, modularized tests, long tests" 
>(https://github.com/sagemath/sage/pull/36498) waiting for review since Oct 
>21, 2023
>- "GH Actions: Build platform-independent wheels of sagemath-environment, 
>sage-setup, sage-sws2rst for PyPI" 
>(https://github.com/sagemath/sage/pull/37099) waiting for review since Feb 5
>- "CI: Update Linux platforms / runners" waiting for review since Feb 14
>- "GH Actions: Build macOS arm64 wheels" 
>(https://github.com/sagemath/sage/pull/37503) waiting for review since Feb 
>28
>- "CI Build: Fix "test modularized distributions" 
>(https://github.com/sagemath/sage/pull/37750) waiting for review since Apr 4
>- "dist.yml: Download optional/experimental tarballs for GitHub Release 
>assets" (https://github.com/sagemath/sage/pull/37762) waiting for review 
>since Apr 6
>
>4. Non-examples (all PRs authored by me, waiting for review):
>- "CI Build: Show segfaults using GitHub annotations" 
>(https://github.com/sagemath/sage/pull/37738, waiting for review) -- this 
>makes changes in sage.doctest, so would continue to be reviewed normally
>- "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run 
>ruff-minimal" (https://github.com/sagemath/sage/pull/37453, waiting for 
>review) -- this also makes changes in src/tox.ini and src/doc, so would 
>continue to be reviewed normally
>- "src/tox.ini (coverage:run): Set concurrency = multiprocessing,threads" 
>(https://github.com/sagemath/sage/pull/37010) -- makes changes in 
>src/tox.ini, so would continue to be reviewed normally
>- "sage -tox -e pyright: Update, speed up, isolate" 
>(https://github.com/sagemath/sage/pull/36515) -- makes changes to 
>pyrightconfig.json and src/tox.ini, so would continue to be reviewed 
>normally
>
>

-- 
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, 

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Dima Pasechnik]

On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe 
wrote:

> I need your help on these PRs. Please vote.
>
> Special expertise is not required for voting. You will find the comments
> in these PRs instructive -- also as illustration for a (long overdue) 
> *discussion
> about governance and review standards* in the Sage project.
>

> *1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561
>  and
> https://github.com/sagemath/sage/pull/37138
> * ("Move metadata from
> setup.cfg to pyproject.toml").
> These are trivial "chore" PRs. They update metadata of our
> pip-installable packages "sage-conf" and "sagemath-standard" to the latest
> format.
> These straightforward and appropriately focused PRs have been held back by
> months by *bundling the review of the PRs with unrelated issues.* I call
> this "artificial friction"; see the discussion in the PRs. To help overcome
> this artificial friction, please vote.
>

This is not true - the friction is not artificial. It is due to legitimate
concerns of developers who are not interested in
spending all of their time on ever growing "Sage the distribution", and/or
who see little merit in Matthias' sagelib modulalisation
project, which uses Python features (most of all, namespace packages)
not universally supported by a number of important tools, such as  Cython
and pytest.

Please vote -1 on these two PRs (there are more similar PRs around). This
will force Matthias to reconsider his priorities, and enable
other voices to be heard. So far, Matthias refuses to reassess the
priorities of the project - instead he puts away
the criticism as "abuse" directed at him.

As a result of this friction, a number of developers have left or about to
leave the project, or are discussing
creation of a hard fork of Sage.

In particular, I think it is urgent to re-access the need for sagelib
modularisation in its current form.
It appears to be harming the project, and its benefits are questionable.

As well, it's urgent to make Sage more modular on the level of Sage the
distribution - the "interesting" part, sagelib,
is getting increasingly entangled in Sage the distribution (which is just a
constantly growing pile of Jupyter, Python, ans Sphinx-related
packages, which Matthias and few others are all too keen on hoarding).
This in particular makes Sage harder and harder to package for Linux, and
other, distributions (Packaging of Sage for Debian/Ubuntu and
Fedora has been stalled for years already).


> *2. Please vote -1 on both https://github.com/sagemath/sage/pull/37387
>  and
> https://github.com/sagemath/sage/pull/36951
> . *These PRs are about a
> Developer Experience issue, namely the workflow on GitHub that notifies
> developers when the HTML documentation is ready for inspection by PR author
> and reviewers. Now a few developers have made it known that they are
> annoyed by the notifications (whether received by email or the notification
> tool on the GitHub website), and the PRs seek to turn off most or all of
> the notifications. That *these notifications enable a productive
> notification-driven development style, and that the notifications serve the
> project's need for quality control on the formatted documentation*, has
> not received meaningful consideration.
>

We are not an enterprise with full-time developers 24 hours a day ready to
react to these endless notifications.
They are spam for almost everyone, and should be turned off.
Please, please vote +1 on them.

What's happening on these PRs is exactly what I had cautioned about in
> https://github.com/sagemath/sage/pull/36726#issuecomment-1820148873
> regarding the (then-proposed, now established) system of majority votes as
> a conflict resolution mechanism for PRs. To balance it, we need the
> involvement of the larger developer community: please vote.
>

No, what we really need is an honest general discussion on directions the
project is taking.
Right now it's going  nowhere, to ever growing pile of bugs noone even
talks about addressing (e.g. Pynac; Maxima;
memory leaks related to Singular; etc etc), to huge package bloat, etc.

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/CAAWYfq1RJSA_WNgvjdiSboxYJ2e7X3h2bwOYh_du82aekdtO0A%40mail.gmail.com.

Re: [sage-devel] Bug in .subgroup?

[Dima Pasechnik]

On Thu, Apr 4, 2024 at 11:07 AM Dima Pasechnik  wrote:
>
> Yes, it's surely a bug; this example gives |gg|=2^27 (wow!), or a smaller one:
>
> sage: g=AbelianGroup([2,2])
> sage: gg=g.subgroup(g.list())
> sage: gg.cardinality().factor() # what?
> 2^3
> sage: g.cardinality().factor()
> 2^2
>
> Maybe related to https://github.com/sagemath/sage/pull/36986 ?

yes, indeed, it came from https://github.com/sagemath/sage/pull/36986
I've opened https://github.com/sagemath/sage/issues/37744

>
> On Thu, Apr 4, 2024 at 10:24 AM 'B. L.' via sage-devel
>  wrote:
> >
> > Hello,
> > to me it seems that with 10.3 there might be a bug in ".subgroup", see 
> > example below. The subgroup cardinality is wrong and the equality test of 
> > the group and the subgroup generated by all group elements yields "False". 
> > In previous versionls of SAGE this worked as expected.
> > Can anybody help?
> > Thanks and kind regards,
> > Barbara
> >
> >
> > sage: g = AbelianGroup([4, 4])
> > sage: gg = g.subgroup(g.list())
> > sage: g
> > Multiplicative Abelian group isomorphic to C4 x C4
> > sage: gg
> > Multiplicative Abelian subgroup isomorphic to C4 x C4 generated by {f1, 
> > f1^2, f1^3, f0, f0*f1, f0*f1^2, f0*f1^3, f0^2, f0^2*f1, f0^2*f1^2, 
> > f0^2*f1^3, f0^3, f0^3*f1, f0^3*f1^2, f0^3*f1^3}
> > sage: g.cardinality()
> > 16
> > sage: gg.cardinality()
> > 134217728
> > sage: g==gg
> > False
> >
> > --
> > 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/55ecbb00-3927-4339-8cb3-f68347358446n%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/CAAWYfq17xtj%2BroU9QWBMF6DV4HmPRg4EmgpXnLRzsad%2BZ8k6MA%40mail.gmail.com.

Re: [sage-devel] Bug in .subgroup?

[Dima Pasechnik]

Yes, it's surely a bug; this example gives |gg|=2^27 (wow!), or a smaller one:

sage: g=AbelianGroup([2,2])
sage: gg=g.subgroup(g.list())
sage: gg.cardinality().factor() # what?
2^3
sage: g.cardinality().factor()
2^2

Maybe related to https://github.com/sagemath/sage/pull/36986 ?

On Thu, Apr 4, 2024 at 10:24 AM 'B. L.' via sage-devel
 wrote:
>
> Hello,
> to me it seems that with 10.3 there might be a bug in ".subgroup", see 
> example below. The subgroup cardinality is wrong and the equality test of the 
> group and the subgroup generated by all group elements yields "False". In 
> previous versionls of SAGE this worked as expected.
> Can anybody help?
> Thanks and kind regards,
> Barbara
>
>
> sage: g = AbelianGroup([4, 4])
> sage: gg = g.subgroup(g.list())
> sage: g
> Multiplicative Abelian group isomorphic to C4 x C4
> sage: gg
> Multiplicative Abelian subgroup isomorphic to C4 x C4 generated by {f1, f1^2, 
> f1^3, f0, f0*f1, f0*f1^2, f0*f1^3, f0^2, f0^2*f1, f0^2*f1^2, f0^2*f1^3, f0^3, 
> f0^3*f1, f0^3*f1^2, f0^3*f1^3}
> sage: g.cardinality()
> 16
> sage: gg.cardinality()
> 134217728
> sage: g==gg
> False
>
> --
> 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/55ecbb00-3927-4339-8cb3-f68347358446n%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/CAAWYfq12wP_ANzFv7RqPVrw1CTDRa8MuU0MA%2BXBXS6RnUGSKHQ%40mail.gmail.com.

Re: [sage-devel] Mysterious .sage behavior

[Dima Pasechnik]

On 31 March 2024 15:23:24 CEST, Marc Culler  wrote:
>This is a follow-up to a user's query in a Sage_macOS issue. 
>
>The current sage-env script contains the excerpt below.  It seems pretty 
>confusing that  Sage would create a directory named .sage/ipython-5.0.0 
>when Sage is shipping IPython 8.18.1.  What would be wrong with calling the 
>directory .sage/profiles/ipython--v1, and moving to ipython--v2 when 
>necessary?  Similarly for jupyter and matplotlib.

I must say I don't know what kind of problems these versioned names are meant 
to solve.

Dima
>
>- Marc
>
>if [ -z "$IPYTHONDIR" ]; then
># We hardcode a version number in the directory name. The idea is
># that we keep using the same version number as long as that is
># possible. Only when some future IPython version really requires
># a new structure for the $IPYTHONDIR should this version number be
># changed to the new IPython version.
>export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0"
>fi
>
>if [ -z "$JUPYTER_CONFIG_DIR" ]; then
># We hardcode a version number in the directory name. The idea is
># that we keep using the same version number as long as that is
># possible. Only when some future Jupyter version really requires
># a new structure for the $JUPYTER_CONFIG_DIR should this version
># number be changed to the new jupyter_core version.
>export JUPYTER_CONFIG_DIR="$DOT_SAGE/jupyter-4.1"
>fi
>
>if [ -z "$MPLCONFIGDIR" ]; then
># We hardcode a version number in the directory name. The idea is
># that we keep using the same version number as long as that is
># possible. Only when some future Matplotlib version really requires
># a new structure for the $MPLCONFIGDIR should this version
># number be changed to the new matplotlib version.
>export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"
>fi
>

-- 
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/49795DE7-7E49-411F-8BDC-098473D6FC7D%40gmail.com.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

On Fri, Mar 29, 2024 at 7:42 PM Dima Pasechnik  wrote:
>
> On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
>  wrote:
> >
> > Workaround with the Sage distribution: "./configure 
> > --without-system-liblzma --without-system-xz"
> > (Our xz package dates back from before the attackers were born;)
> >
> > Incidentally, the cryptographic protection of the Sage distribution is 
> > wildly insufficient.
> > I've opened https://github.com/sagemath/sage/issues/37691 for this -- any 
> > takers?
>
> I'd switch to sha256.
> And require PGP-signed commits, etc.
>
> well, I can't even comment on that issue :-)

By the way, the essential part of xz backdoor was sneaked in as a
modified  copy of a gnulib m4 macros file.
As this is "the" way to use gnulib - just vendor what they provide in
your source code - one may wonder again
about the virtues of vendoring a lot of code.
Potentially, any tarfile we host  may contain an exploit.

As well as anything produced on CI, VM, or, real, hosts running
compromised OS (latest unstable versions of Debian and Fedora were
compromised with this xz hack, Homebrew was, as well). So this is
something to review urgently, too.

Dima




>
>
> >
> >
> > On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote:
> >>
> >> https://www.openwall.com/lists/oss-security/2024/03/29/4
> >>
> >> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
> >> you have a backdoored xz.
> >
> > --
> > 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/d75e7cc9-9743-4c20-b502-431d400dc5f2n%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/CAAWYfq1w9X3aZ3z8U%3DC_BFD8Ffh_tE3JfNBGoSV%3DYYiFE2Guxg%40mail.gmail.com.

[sage-devel] testing notebooks with pytest --nbval ?

[Dima Pasechnik]

Is anyone testing their Sage Jupyter notebooks with pytest --nbval ?
I imagine that for collections of notebooks this can be used to set up CI tests.

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/CAAWYfq3qx3rwqCnUReDknQ7Rn38LwSbZ0LzGnQsvjh7k6EHkxA%40mail.gmail.com.

[sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

and Homebrew.
Please upgrade your Homebrew. It should do a downgrade:

`brew upgrade` now "upgrades" xz from 5.6.1 -> 5.4.6

On Fri, Mar 29, 2024 at 7:36 PM Dima Pasechnik  wrote:
>
> aand Conda: https://anaconda.org/anaconda/xz shows version 5.6.1
>
> On Fri, Mar 29, 2024 at 7:18 PM Dima Pasechnik  wrote:
> >
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
> > you have a backdoored xz.

-- 
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/CAAWYfq3%3DOQprCMf%3Dv2ubAoZVhFEHBSjf52LT9XHAR8nRiOR3GA%40mail.gmail.com.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
 wrote:
>
> Workaround with the Sage distribution: "./configure --without-system-liblzma 
> --without-system-xz"
> (Our xz package dates back from before the attackers were born;)
>
> Incidentally, the cryptographic protection of the Sage distribution is wildly 
> insufficient.
> I've opened https://github.com/sagemath/sage/issues/37691 for this -- any 
> takers?

I'd switch to sha256.
And require PGP-signed commits, etc.

well, I can't even comment on that issue :-)


>
>
> On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote:
>>
>> https://www.openwall.com/lists/oss-security/2024/03/29/4
>>
>> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
>> you have a backdoored xz.
>
> --
> 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/d75e7cc9-9743-4c20-b502-431d400dc5f2n%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/CAAWYfq3zGy3RRBaUpi_rS57dG7s6fP5i78K2Pseyw5paN6_roQ%40mail.gmail.com.

[sage-devel] Re: xz/liblzma has been compromised

[Dima Pasechnik]

aand Conda: https://anaconda.org/anaconda/xz shows version 5.6.1

On Fri, Mar 29, 2024 at 7:18 PM Dima Pasechnik  wrote:
>
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
> you have a backdoored xz.

-- 
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/CAAWYfq3TfwUtW%2B4ZV0GMr4egCUsrgjHTrTtzuVeKi5ARj4tuUA%40mail.gmail.com.

[sage-devel] xz/liblzma has been compromised

[Dima Pasechnik]

https://www.openwall.com/lists/oss-security/2024/03/29/4

if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
you have a backdoored xz.

-- 
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/CAAWYfq0T0eMogYB0K6isVEQy%3DL2JGfQMPrQwEXF_ECMmtiA4%2Bw%40mail.gmail.com.

Re: [sage-devel] Something wrong kept happening , pls help

[Dima Pasechnik]

On Friday, March 29, 2024 at 3:50:23 AM UTC Cassidy Taylor wrote:


Thank you for your reply!
However I cant change or update my conda environment cause the code I want 
to replicate (which called AgentNet)  have already specified restrictions 
on conda environment and other needed library versions such as pytorch 
1.11.0. 

But I will try to download sage 10.2 on my present conda 11.3 environment.


We are talking about https://github.com/KarolisMart/AgentNet

I am not entirely sure what the problem is. I am not sure why you ended up 
with errors building GMP.
Please explain exactly what you did.
I suppose you
1) installed Conda (on a Linux box or a Linux VM)
2) checked out https://github.com/KarolisMart/AgentNet
3) ran "conda env create -f environment.yml"

None of this should involve any compilation - as it's meant to use 
pre-built Conda packages.

 

Anyway , thank you again and wish you have a great day!
在2024年3月27日星期三 UTC+8 17:42:28 写道：

Hello,

your installation shows sage 9.6, but conda carries sage 10.2 now:
https://anaconda.org/conda-forge/sage

That's one you should be getting if you follow
https://doc.sagemath.org/html/en/installation/conda.html

Could it be that your conda environment needs an update?

HTH
Dima



On Wed, Mar 27, 2024 at 9:11 AM Cassidy Taylor  wrote:

Everytime I tried to download Sagemath in the conda environment I created 
on Ubuntu , the terminal kept showing this error(fig.1) . It shows that 
there is something wrong with the download of gmp-6.2.1(fig.2) , seemed 
like it is my C++ compiler not available. 
[image: 微信图片_20240327153329.png]

[image: 微信图片_20240327153257.png]

​BUT I have searched for so many days and so many ways , and I have checked 
that my C++ compiler is already downloaded(fig.3) god knows how many times, 
besides I also downloaded gmp-6.2.1.tar.zst on my ubuntu system. 
​
[image: 微信图片_20240327153307.png]
Pls reply ASAP , this really set back my postgraduate career...
Looking forward to your answering , thank you !

-- 
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+...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e6cad138-72a3-4406-b951-6b5ec4c40ed8n%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/914a98f7-837c-4055-ae8e-e64dd5518a6dn%40googlegroups.com.

Re: 与“[sage-devel] Something wrong kept happening , pls help”相关的私人帖子

[Dima Pasechnik]

On Thu, Mar 28, 2024 at 2:08 PM Cassidy Taylor  wrote:

> Happy to hear you back! 
> I have two questions want to ask now , first one is why I couldnt see my
> reply on Google Group sage-devel in our conversation? Seems like I can only
> start a conversation but cannot reply anyone?樂
>

you can use either a desktop/laptop browser to assess Google Group
interface - there you can reply.

Or you can use email interface  - sending emails and replies to
sage-devel@googlegroups.com.
(I cc this message there)



And the second one is kinda interesting which is the code I want to
> reproduce named AgentNet is "another" AgentNet , it is launched in 2023 on
> ICLR with full name "AGENT-BASED GRAPH NEURAL NETWORKS" and the author
> is Karolis Martinkus, the screenshot of this code is fig.1.
>

it seems to be using Sage in a very restricted way - using it to  generate
some particular graphs.
You cam remove the dependence on sage with a little work (adapting Sage's
code to using networkx's graphs instead)

Otherwise you could try removing fixed version constraints in AgentNet's
environment.yml, in hope that then Conda will be able to resolve the
environment.

HTH
Dima


>
> Dima Pasechnik  于2024年3月28日周四 20:34写道：
>
>>
>>
>> On Thu, Mar 28, 2024 at 3:54 AM Cassidy Taylor 
>> wrote:
>>
>>> Thank you for your reply!
>>> However I cant change or update my conda environment cause the code I
>>> want to reproduce (which is called  AgentNet) have already  specified
>>> restrictions on conda environment and other required library versions.
>>> But I wil try to download sage 10.2 on my conda-11.3 environment.
>>>
>>
>> AgentNet has not been updated for 7 years, and its GitHub repo is
>> "archived"
>> Getting it to work in 2024 might need more work - or, perhaps, using a
>> different tool all together.
>>
>> https://github.com/yandexdataschool/AgentNet
>>
>>
>>
>>> Anyway, thank you again and wish you have a great day!
>>>
>>> 在2024年3月27日星期三 UTC+8 17:42:28 写道：
>>>
>>> Hello,
>>>
>>> your installation shows sage 9.6, but conda carries sage 10.2 now:
>>> https://anaconda.org/conda-forge/sage
>>>
>>> That's one you should be getting if you follow
>>> https://doc.sagemath.org/html/en/installation/conda.html
>>>
>>> Could it be that your conda environment needs an update?
>>>
>>> HTH
>>> Dima
>>>
>>>
>>>
>>> On Wed, Mar 27, 2024 at 9:11 AM Cassidy Taylor 
>>> wrote:
>>>
>>> Everytime I tried to download Sagemath in the conda environment I
>>> created on Ubuntu , the terminal kept showing this error(fig.1) . It shows
>>> that there is something wrong with the download of gmp-6.2.1(fig.2) ,
>>> seemed like it is my C++ compiler not available.
>>> [image: 微信图片_20240327153329.png]
>>>
>>> [image: 微信图片_20240327153257.png]
>>>
>>> BUT I have searched for so many days and so many ways , and I have
>>> checked that my C++ compiler is already downloaded(fig.3) god knows how
>>> many times, besides I also downloaded gmp-6.2.1.tar.zst on my ubuntu
>>> system.
>>>
>>> [image: 微信图片_20240327153307.png]
>>> Pls reply ASAP , this really set back my postgraduate career...
>>> Looking forward to your answering , thank you !
>>>
>>> --
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/e6cad138-72a3-4406-b951-6b5ec4c40ed8n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/sage-devel/e6cad138-72a3-4406-b951-6b5ec4c40ed8n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>>

-- 
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/CAAWYfq2sZpW58yOT07_99bGw_AZXZVbpT%3D_yoWfpyp4gnhja6g%40mail.gmail.com.

[sage-devel] Re: Bug in quadratic_defect

[Dima Pasechnik]

On Sunday, March 24, 2024 at 4:02:25 PM UTC Nils Bruin wrote:

On Sunday 24 March 2024 at 04:41:25 UTC-7 Przemysław Koprowski wrote:

Let me just comment on your words "searching the source, this routine isn't 
actually used elsewhere in sage" (here: 
https://github.com/sagemath/sage/pull/37657). It is not entirely true, 
because, as far as I know, the method is_padic_square (in the class of a 
number field element) internally relies on the quadratic_defect.

Thanks! I based my assessment on the search result that github returned for 
`quadratic_defect`. It only returned two hits for me.
Lesson: Don't rely on github search. It's far from exhaustive. 


indeed, entries in src/sage/rings/number_field/number_field.py are just 
missing in GitHub search. I filed a "feedback". 

-- 
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/1c8cefe6-0a14-4a93-91fb-da1c09ab5984n%40googlegroups.com.

Re: [sage-devel] Re: Bug in quadratic_defect

[Dima Pasechnik]

issues are for the cases without an already ready solution, or for something 
longer term than just one PR

On 23 March 2024 16:55:50 GMT, Nils Bruin  wrote:
>Thanks! this is now 
>
>https://github.com/sagemath/sage/issues/37656
>
>or
>
>https://github.com/sagemath/sage/pull/37657
>
>(I'm still a bit murky on what issues are used for)
>
>-- 
>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/ef63a7c8-845f-4cee-90c9-beca953568ban%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/70996D3D-A3D4-4EC0-9DE4-076D23D1F873%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On 22 March 2024 23:01:47 GMT, Matthias Koeppe  wrote:
>On Friday, March 22, 2024 at 3:31:07 PM UTC-7 Dima Pasechnik wrote:
>
>They are not really "tested" - just as much of the rest of Jupiter stuff is 
>not tested in our CI.
>
>(installability - yes, 
>
> 
>The installability of it is exactly what was broken in Sage 10.2. 
>We test automatically so that we do not have to wait for users' bug reports.
>
>in a strange non-standard environment,
>
>
>The installability of the package is tested in the relevant environment, 
>namely the Sage venv.
>
>I need to ask you to drop these mischaracterizations of the Sage venv as 
>something "strange" or "non-standard". There's no technical basis for this, 


Of course it is strange and non-standard.
A custom venv, non-standard commands to launch things, pinned to seemingly 
random values versions of packages, etc.

>and repeating it is harmful to the project. 
>https://groups.google.com/g/sage-devel/c/OeN8o14s6Jc
>
>but whether the notebooks actually work, who knows)
>
>
>We know because the reviewer of the upgrade 
>ticket https://github.com/sagemath/sage/pull/37478 tested it. 

you claimed they are tested by CI, not by humans.


>

-- 
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/61B136FB-2D22-4523-A59B-07ED765DF12B%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

I don't think that one would look for e.g. a Jupyter interface to Pari-GP in 
the catalog of sage spkgs.

The natural place is Pari-GP website.

They are not really "tested" - just as much of the rest of Jupiter stuff is not 
tested in our CI.
(installability - yes, in a strange non-standard environment, but whether the 
notebooks actually work, who knows)

pytest has a special plugin, nbmake, to test notebook, and testing notebook 
kernels/clients ought to involve running actual notebooks on them.

Jupyter interface for Singular seems to be an old beta, and it's just funny to 
try to offer anything for R, given how big R is compared to Sage.

Let's drop them all from Sage distribution.




On 22 March 2024 21:40:24 GMT, Matthias Koeppe  wrote:
>On Friday, March 22, 2024 at 12:02:30 PM UTC-7 Nils Bruin wrote:
>
>It looks to me like a project that can easily not be offered as an spkg, 
>with minimal effect, but I might be overlooking something. 
>
>
>What you might be overlooking is that 
>- our catalog of SPKGs is a useful curation that serves our users;
>- our workflows on GH Actions automatically test the packages in our 
>catalog on every release.
>
>-- 
>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/106f3ff1-42c1-469b-a536-7de0857c0080n%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/CFECCC91-D26A-483F-A4FC-4AB4BBD298A5%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On 22 March 2024 19:02:30 GMT, Nils Bruin  wrote:
>On Friday 22 March 2024 at 11:22:12 UTC-7 Matthias Koeppe wrote:
>
>10 days ago, the previous maintainer, Vincent Delecroix, announced that he 
>steps down from maintaining it. 
>https://groups.google.com/g/sage-devel/c/fy1ei6bLtmc
>I did some emergency maintenance and on that occasion I added the 
>"Maintainers" field in the metadata. Nobody specifically committed to 
>maintaining it or made a plan, as far as I know.
>
>
>Thanks for that. Obviously, when a maintainer steps down, some follow-up 
>should happen and by the location of the repository, the sagemath community 
>inherits the project in this case by default.
>
>It looks to me like a project that can easily not be offered as an spkg, 
>with minimal effect, but I might be overlooking something. So removing the 
>spkg could make sense.

There are also similarly disjoint from Sage packages r-jupyter, 
singular-jupyter, see


they can similarly be removed from Sage.
(but mentioned in the docs)


>
>Judging from the thread here:
>
>https://pari.math.u-bordeaux.fr/archives/pari-dev-2305/msg2.html
>
>this kernel is very much the basis for whatever Bill is considering. 
>Further down the thread, there is also a reference to Edgar Costa's kernel:
>
> https://github.com/edgarcosta/gp_kernel
>
>it looks like the discussion there may lead to a new home for the project 
>eventually (or another project to take its place).
>

-- 
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/B3CC456D-14F1-454B-A594-84CE4877765E%40gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On Fri, Mar 22, 2024 at 5:13 PM Matthias Koeppe 
wrote:

> Let me just point out that the idea that "grant has ended, so we can kill
> its deliverables" is fundamentally flawed, and certainly is not and cannot
> be the position of our project.
>
> Infrastructure grants are exactly set up for their longer-term and broader
> impacts.
>

the bundling with SageMath was rather artificial in this case, and anyway
OpenDreamKit had more deliverables which were not meant to be bundled at
all.

Nobody says "kill it".
It's a standalone  PyPI project which does not use anything in SageMath,
nor it is used from SageMath.
It can be installed from PyPI if anyone needs it.




>
> Matthias
>
> On Friday, March 22, 2024 at 5:58:47 AM UTC-7 Dima Pasechnik wrote:
>
>> I don't see any reason for pari-jupyter being a sage package. It has
>> nothing in common with sagelib, it's a standalone jupyter kernel for
>> Pari-GP.
>> It has ended up in sage in OpenDreamKit times, to make granting agency
>> happy.
>>
>>
>> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  wrote:
>>
>>> Bill Allombert has been working on a kernel via xeus:
>>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>>> Which addresses many of the issues with the current one.
>>> While we for its first stable release, I recommend mine:
>>> https://github.com/edgarcosta/gp_kernel/
>>> where I have addressed many of the issues, by going through the route
>>> that every cell is a temporary file, which is loaded in gp.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe 
>>> wrote:
>>>
>>>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>>>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just
>>>> point to the main sagemath repository
>>>> - using WIP sage-project-cookiecutter to simplify maintenance
>>>> https://github.com/sagemath/sage/pull/37541
>>>>
>>>> --
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> 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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/c681d272-5561-4ef9-bdcc-33a1d503cee0n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/c681d272-5561-4ef9-bdcc-33a1d503cee0n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAAWYfq2fci92VKp6c0mRxUt%2BVBzwBprMxQyENwsLa2n--uxHbw%40mail.gmail.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Dima Pasechnik]

On Fri, Mar 22, 2024 at 3:01 PM Marc Culler  wrote:

> If one has Sage installed with the pari-jupyter package installed in Sage
> and one wants to run pari-jupyter, what does one do?  Is it equivalent to
> just installing pari-jupyter with pip and starting it up in the normal way?
>

I have pari+libpari installed systemwide. Then  installs pari-jupyter well
in a clean python 3.11 venv
Then I can run

pip install jupyterlab
jupyter kernelspec install --user
$(pwd)/share/jupyter/kernels/pari_jupyter


Then

jupyter lab

brings up a browser window with all the right notebooks, I can start
Pari-GP notebook, etc




> Does pari-jupyter use any components of Sage?  If the answers are "yes"
> and "no", then I agree that it is hard to see any reason why it should be a
> Sage package.
>

no, I don't think it does. Remove?

Dima


>
> - Marc
>
> On Friday, March 22, 2024 at 7:58:47 AM UTC-5 Dima Pasechnik wrote:
>
>> I don't see any reason for pari-jupyter being a sage package. It has
>> nothing in common with sagelib, it's a standalone jupyter kernel for
>> Pari-GP.
>> It has ended up in sage in OpenDreamKit times, to make granting agency
>> happy.
>>
>>
>> On Thu, Mar 21, 2024 at 8:42 AM Edgar Costa  wrote:
>>
>>> Bill Allombert has been working on a kernel via xeus:
>>> https://pari.math.u-bordeaux.fr/git/xeus-gp.git/
>>> Which addresses many of the issues with the current one.
>>> While we for its first stable release, I recommend mine:
>>> https://github.com/edgarcosta/gp_kernel/
>>> where I have addressed many of the issues, by going through the route
>>> that every cell is a temporary file, which is loaded in gp.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:29 AM Matthias Koeppe 
>>> wrote:
>>>
>>>> - https://pypi.org/project/pari-jupyter/1.4.3rc1/
>>>> - I've added simple CODE_OF_CONDUCT and CONTRIBUTING files that just
>>>> point to the main sagemath repository
>>>> - using WIP sage-project-cookiecutter to simplify maintenance
>>>> https://github.com/sagemath/sage/pull/37541
>>>>
>>>> --
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/sage-devel/e822f186-6504-4516-9940-d03398f270b9n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> 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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/sage-devel/CA%2BiQ7x5FYigLmaKMc0wodYJB9BUqsdpyuy63RrxXoTcv%2BQKTJw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/2648a303-6b46-40d7-8a2e-1eb4f319e7ecn%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/2648a303-6b46-40d7-8a2e-1eb4f319e7ecn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAAWYfq3hnQBA%3DSRAnkC2ALCQD0fcbZGiCSrAKLYDwUu7wbUwCw%40mail.gmail.com.