date:20240212

+1 from me to the original 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/bbfc79f9-b1f4-43fa-8987-e6fb155fd914n%40googlegroups.com.

[sage-devel] Re: One year of Sage development on GitHub



On Monday, February 12, 2024 at 3:42:55 PM UTC+9 Matthias Koeppe wrote:

On Thursday, February 8, 2024 at 10:16:58 AM UTC-8 Matthias Koeppe wrote:

*2. Is our community aware of the sagemath/sage GitHub wiki?* 
https://github.com/sagemath/sage/wiki
- Are the contents of the wiki front page useful?


Meanwhile I have edited it a bit to offer "suggested activities".
(This is based on a version of the Trac wiki front page just before the 
transition to GitHub.


The content of the added section does not give new info and seems just 
visual noise to me...



 

-- 
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/8fb52b6b-4dd9-4384-813e-1965f42ca328n%40googlegroups.com.

Re: [sage-devel] One year of Sage development on GitHub

2024-02-12 Thread 'Martin R' via sage-devel

For me - personally - the problem that Vincent pointed out has an emotional 
flavour: most of the threads on sage-devel are on (lcertainly important) 
technicalities.  The discussion about how to implement math has mostly 
moved to github, and split into very very many issues that are hard to find 
and hard to follow.

The efforts to sort issues by topic are therefore very important to me.  It 
is a bit sad that search on github is even worse than on google groups - 
there is no way to seach for partial words.

Martin
On Tuesday 13 February 2024 at 02:23:05 UTC+1 Matthias Koeppe wrote:

> On Monday, February 12, 2024 at 4:58:05 PM UTC-8 Nils Bruin wrote:
>
>
> Each of those components could definitely use attention. However, the 
> skill set required to work on those components is quite different from that 
> on working on (re)packaging existing, maintained python projects. People 
> choose what they work on. I think we have a problem if we don't have anyone 
> willing/able to work on pynac or singular or maxima. But I'm not sure this 
> has very much to do with people working on (re)packaging other software.
>
>
> Exactly!
>
>
>

-- 
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/5214a72a-1ddc-46c1-b601-86a300ac79c4n%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements



On Thursday, February 8, 2024 at 11:15:34 AM UTC+9 Kwankyu Lee wrote:

A method (or function) takes objects as input and computes an output.  The 
INPUT block defines coarsely  the intended class of mathematical objects. 

TypeError: the type (that can be checked by isinstance(obj, class)) of the 
input object does not belong to the intended class of mathematical objects
ValueError: the particular input object is not suitable as input
ArithmeticError: the particular input object is not suitable for arithmetic 
(sum, product, quotient, and the like) operation 
ZeroDivisionError: the method performs division but the input is zero
NotImplementedError: there is no problem with the input object but the 
method is incapable to compute appropriate output.
RuntimeError: The method somehow cannot perform the computation. Perhaps a 
catchall error.


I may add the above to the developer guide. Any comments? 


Implemented in 

https://github.com/sagemath/sage/pull/37311 

-- 
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/62552750-b841-40c7-8054-d59951d49e76n%40googlegroups.com.

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

2024-02-12 Thread 'tobia...@gmx.de' via sage-devel

+1 for both proposals.

Via "pip download" (https://pip.pypa.io/en/stable/cli/pip_download/) it is 
easy to resolve and download all pip packages on a system with internet 
connection, and then later on the target system install it without the need 
for internet.

On Tuesday, February 13, 2024 at 9:42:07 AM UTC+7 Matthias Koeppe wrote:

> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>
> In any use cases with internet connectivity, people will be better off by 
> just cloning the git repo, not use the release tarball.
>
> If there are relevant use cases without internet connectivity (I have no 
> opinion to offer on this), then the release tarball has exactly the right 
> contents.
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
>
> That's now https://github.com/sagemath/sage/pull/37309 (needs review)
>  
>
> *B. *Likewise, get rid of all of these "Download Sage source code" pages (
> https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
>
> That's now https://github.com/sagemath/website/pull/466
>  
>

-- 
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/1b90f070-914f-45a6-bd4f-7a207b05448en%40googlegroups.com.

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

On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:

In any use cases with internet connectivity, people will be better off by
just cloning the git repo, not use the release tarball.

If there are relevant use cases without internet connectivity (I have no
opinion to offer on this), then the release tarball has exactly the right
contents.

*Proposed action items: *
*A.* Change https://github.com/sagemath/sage/blob/develop/README.md so that
"git clone" is described as the primary way to obtain the Sage sources.
That the big release tarball is available can be a footnote in the
Installation Guide (
https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)

for the limited no-internet connectivity use case.

That's now https://github.com/sagemath/sage/pull/37309 (needs review)

*B. *Likewise, get rid of all of these "Download Sage source code" pages (
https://www.sagemath.org/download-source.html,
https://www.sagemath.org/download-latest.html), mirror selection, etc. from
the Sage website.

That's now https://github.com/sagemath/website/pull/466

--
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/1cb9073b-3459-4a36-ae09-f32fba92ffb6n%40googlegroups.com.

Re: [sage-devel] One year of Sage development on GitHub

On Monday, February 12, 2024 at 4:58:05 PM UTC-8 Nils Bruin wrote:


Each of those components could definitely use attention. However, the skill 
set required to work on those components is quite different from that on 
working on (re)packaging existing, maintained python projects. People 
choose what they work on. I think we have a problem if we don't have anyone 
willing/able to work on pynac or singular or maxima. But I'm not sure this 
has very much to do with people working on (re)packaging other software.


Exactly!


-- 
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/6fab4d7f-7566-47cb-a432-458b3edd5146n%40googlegroups.com.

Re: [sage-devel] One year of Sage development on GitHub

2024-02-12 Thread Nils Bruin

On Monday 12 February 2024 at 15:58:11 UTC-8 Dima Pasechnik wrote:

What's rotten and decaying - well, the most obvious points are:

* pynac (memory leaks, bugs, sketchy or no docs, authors left long time
ago)

* commutative algebra, in particular Singular-based (memory leaks,
bugs, no docs, authors either left or are not willing to look into it
much), etc.

* maxima (bugs, bugs, bugs)

* broken optional packages, e.g. p_group_cohomology

Each of those components could definitely use attention. However, the skill
set required to work on those components is quite different from that on
working on (re)packaging existing, maintained python projects. People
choose what they work on. I think we have a problem if we don't have anyone
willing/able to work on pynac or singular or maxima. But I'm not sure this
has very much to do with people working on (re)packaging other software.

The discussion about whether a sage-the-distribution should exist and how
it relates to sage-the-library definitely needs to be resolved at some
point and, whatever decision is made, people need to accept that's the
consensus and move on until the next time it needs to be reconsidered, but
I don't think that the resolution of that issue will alleviate the lack of
maintainers of pynac etc.

--
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/2bf356de-c6be-402e-9278-55e901469ec7n%40googlegroups.com.

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

On Mon, Feb 12, 2024 at 11:52 PM Matthias Koeppe
 wrote:
>
> I'll now offer:
>
> Opinion 1. Nobody needs to care in the slightest what the size of that 
> release tarball is.

Not quite true. E.g. the  mirrors are not of infinite size, e.g. some
projects (symengine is an example, IIRC) on PyPI get constrained that
way.

>
> In any use cases with internet connectivity, people will be better off by 
> just cloning the git repo, not use the release tarball.
>
> If there are relevant use cases without internet connectivity (I have no 
> opinion to offer on this), then the release tarball has exactly the right 
> contents.

This won't be true any more if we allow standard packages to be pip packages.

>
> Proposed action items:
> A. Change https://github.com/sagemath/sage/blob/develop/README.md so that 
> "git clone" is described as the primary way to obtain the Sage sources. That 
> the big release tarball is available can be a footnote in the Installation 
> Guide 
> (https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  for the limited no-internet connectivity use case.
>
> B. Likewise, get rid of all of these "Download Sage source code" pages 
> (https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. from 
> the Sage website.
>
>
> On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 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/f926e074-9803-4335-b128-29398c460b0en%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/CAAWYfq0QmtZ5hY39%3DSmfmdtP97wqnQDBstRq7iAd_EwVJHHxXw%40mail.gmail.com.

Re: [sage-devel] One year of Sage development on GitHub

On Mon, Feb 12, 2024 at 6:55 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
> I fully second the observation of Michael though it might have few to
> do with the github switch. Sage development nowadays does not seem to
> be anymore about math research and efficient computations but mostly
> about "dependencies", "infrastructure" and "maintenance". I am always
> depressed by reading the change logs. It might have been a reasonable
> thing if sage was a "stable core Computer Algebra System" on which
> further specialized math research libraries would depend on.

Indeed, it doesn't have much to do with switching to GitHub. The
problem is that we don't have a
"stable core", we have a rotting, decaying core, which is in no way
helped by spending time on
micromanaging versions of every tiny piece of Jupyter, Sphinx, Python
build infrastructure, etc.
Something that other maths Python projects (apart from Anaconda) just
accept as given.

What's rotten and decaying - well, the most obvious points are:


* pynac (memory leaks, bugs, sketchy or no docs, authors left long time ago)

* commutative algebra, in particular Singular-based (memory leaks,
bugs, no docs, authors either left or are not willing to look into it
much), etc.

* maxima (bugs, bugs, bugs)

* broken optional packages, e.g. p_group_cohomology




>  But the
> latter is not the official nor advised way of doing things.
>
> On Thu, 8 Feb 2024 at 14:02, Michael Orlitzky  wrote:
> >
> > On Thu, 2024-02-08 at 11:30 +, Dima Pasechnik wrote:
> > >
> > > We should not try to compete, in effect, with Conda etc, yet we do. This 
> > > is
> > > the primary reason for slowness.
> > >
> >
> > My personal stats for the year 2023-02-08 through 2024-02-08:
> >
> >   Commits: 423
> >   Reviews: 38
> >
> > Zero of those have anything to do with mathematics.
> >
> > --
> > 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/665f0fd945ca6301e75489e1922fb03462cda021.camel%40orlitzky.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/CAGEwAAmCkF%2Bj1XUQEuAK2B%3DD6WDT8Ejk9qrVBZ6fVvxg8H19EQ%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/CAAWYfq3GidPRiSx_JO3MiFXXYvM9fbfc7b1K0_a%2B41Vi62HhEw%40mail.gmail.com.

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

I'll now offer:

*Opinion 1. Nobody needs to care in the slightest what the size of that 
release tarball is. *

In any use cases with internet connectivity, people will be better off by 
just cloning the git repo, not use the release tarball.

If there are relevant use cases without internet connectivity (I have no 
opinion to offer on this), then the release tarball has exactly the right 
contents.

*Proposed action items: *
*A.* Change https://github.com/sagemath/sage/blob/develop/README.md so that 
"git clone" is described as the primary way to obtain the Sage sources. 
That the big release tarball is available can be a footnote in the 
Installation Guide 
(https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)

for the limited no-internet connectivity use case.

*B. *Likewise, get rid of all of these "Download Sage source code" pages 
(https://www.sagemath.org/download-source.html, 
https://www.sagemath.org/download-latest.html), mirror selection, etc. from 
the Sage website. 

On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 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/f926e074-9803-4335-b128-29398c460b0en%40googlegroups.com.

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

2024-02-12 Thread John H Palmieri

What does this (a discussion of how Sage specifies version restrictions) 
have to do with the proposal? If it's relevant, that was not clear in the 
original proposal, so please clarify. It sounds like you might be proposing 
removing version checks on many of the packages Sage uses, or at least 
that's a conclusion I might draw from your critique of the amount of 
maintenance for Sage packages. Or maybe you are proposing redesigning the 
version specification system? In any case, it wasn't stated as part of the 
original proposal, so I don't know what was intended. If it is not relevant 
to the proposal, let's drop this part of the discussion.

I would also suggest dropping the question of whether we're "vendoring." 
The proposal clearly says that we should stop distributing the tarballs in 
the upstream directory, so whatever we call it, that part is clear.

(Maybe by "vendoring" you meant the combination of including the tarballs 
and the maintenance on the allowed versions, or maybe just including the 
tarballs, or maybe something else. The word "vendoring" does not seem to be 
helpful, so instead spelling out exactly what's meant for Sage could be 
helpful, at least if you meant more than just removing "upstream".)

On Monday, February 12, 2024 at 3:07:38 PM UTC-8 Dima Pasechnik wrote:

> On Mon, Feb 12, 2024 at 10:01 PM Matthias Koeppe
>  wrote:
> >
> > On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
> >
> > requirements.txt might as well specify the range, and this is used too 
> e.g.
> >
> > build/pkgs/phitigra/requirements.txt has
> > phitigra>=0.2.6
> >
> >
> > Yes, as I said in 
> https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ, 
> ""Pip" packages can either be pinned to a specific version, or set 
> acceptable version ranges, or be entirely unconstrained. This is set in the 
> file requirements.txt in the package directory."
> >
> > So this is all [...] confusing
> >
> >
> > That's why I'm taking the time to explain it clearly for the benefit of 
> everyone.
>
> I am sorry: I claimed that Sage has about 5 different ways to
> specify/restrict versions of its packages,
> and this makes it hugely confusing.
> You disagreed, but now you say that it needs an explanation.
>
> What really needs an explanation is how we ever went this far on a
> garden path. :-)
>

-- 
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/b89c5e20-0fb0-4c92-8333-4f1766a2bfa1n%40googlegroups.com.

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

On Mon, Feb 12, 2024 at 10:01 PM Matthias Koeppe
 wrote:
>
> On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
>
> requirements.txt might as well specify the range, and this is used too e.g.
>
> build/pkgs/phitigra/requirements.txt has
> phitigra>=0.2.6
>
>
> Yes, as I said in 
> https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ, ""Pip" 
> packages can either be pinned to a specific version, or set acceptable 
> version ranges, or be entirely unconstrained. This is set in the file 
> requirements.txt in the package directory."
>
> So this is all [...] confusing
>
>
> That's why I'm taking the time to explain it clearly for the benefit of 
> everyone.

I am sorry: I claimed that Sage has about 5 different ways to
specify/restrict versions of its packages,
and this makes it hugely confusing.
You disagreed, but now you say that it needs an explanation.

What really needs an explanation is how we ever went this far on a
garden path. :-)

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

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

On Mon, Feb 12, 2024 at 10:11 PM Matthias Koeppe
 wrote:
>
> On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
>
> > 2. Also the large Sage source tarball does not "vendor". It is a shipment 
> > of a distribution. Distributions don't "vendor". It's the job of a 
> > distribution to ship its components.
> This is not correct. Sage is not a distribution
>
>
> Let's not do "Sage-the-distribution is not a distirbution" again. 
> https://groups.google.com/g/sage-devel/c/3Zoq0CNE1hE/m/tPgFOpHWBwAJ (2023).

I never agreed with William on this one (Sage is too narrow in scope
and incomplete to be a distribution),
Anaconda calls itself "distribution", Sage is quite far from
Anaconda's functionality.

Anyway, William concludes with "I hope soon Sage isn't a distribution,
but right now it still is. "
Do you also hope for the latter?

Anyhow, it's just fuzzy terminology, as well as just what exactly "to
vendor" means.
With the definition of "to vendor" I provided then you got to agree
that we vendor a lot of things.

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

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

On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:

> 2. Also the large Sage source tarball does not "vendor". It is a shipment 
of a distribution. Distributions don't "vendor". It's the job of a 
distribution to ship its components.
This is not correct. Sage is not a distribution


Let's not do "Sage-the-distribution is not a distirbution" again. 
https://groups.google.com/g/sage-devel/c/3Zoq0CNE1hE/m/tPgFOpHWBwAJ (2023).

-- 
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/93e3aedc-ad58-4048-8833-f38238d6b874n%40googlegroups.com.

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

On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:

requirements.txt might as well specify the range, and this is used too e.g.

build/pkgs/phitigra/requirements.txt has
phitigra>=0.2.6


Yes, as I said 
in https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ, 
""Pip" packages can either be pinned to a specific version, or set 
acceptable version ranges, or be entirely unconstrained. This is set in the 
file requirements.txt in the package directory."

So this is all [...] confusing


That's why I'm taking the time to explain it clearly for the benefit of 
everyone.

-- 
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/c798c68c-66a5-4d6a-a3e9-2f1ff0c6f1c9n%40googlegroups.com.

Re: [sage-devel] One year of Sage development on GitHub

On Monday, February 12, 2024 at 10:55:37 AM UTC-8 Vincent Delecroix wrote:

Sage development nowadays does not seem to
be anymore about math research and efficient computations but mostly
about "dependencies", "infrastructure" and "maintenance". I am always
depressed by reading the change logs. It might have been a reasonable
thing if sage was a "stable core Computer Algebra System" on which
further specialized math research libraries would depend on.

Isn't your https://github.com/flatsurf/sage-flatsurf project doing exactly
that?

But the
latter is not the official nor advised way of doing things.

What are you talking about? It's the intentional result of over a decade of
the project's policy of sending potential contributors away to go do their
contributions in separately maintained projects.

We have a working mechanism to advertise such projects in our manual.
- We have an index of packages:
https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/#optional-packages
- We have a page for each
package:
https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/sage_flatsurf#spkg-sage-flatsurf
- We have a process for adding package:
https://github.com/sagemath/sage/issues/31164

What we don't have is a clear process to include news about the projects in
our release notes.
https://github.com/sagemath/sage/wiki/Sage-10.3-Release-Tour

Such contributions to the release notes would be very welcome!

That's by the way a downside of including the project in Sage only as a
"pip" package without pinning the version: There's never a PR that bumps
the version, hence it does not appear in the Github-generated changelog,
and hence there is nothing that prompts anyone to add a narrative to our
release notes.

--
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/7c980af6-041b-40db-a58e-ba69872c66ecn%40googlegroups.com.

Re: [sage-devel] One year of Sage development on GitHub

2024-02-12 Thread Vincent Delecroix

I fully second the observation of Michael though it might have few to
do with the github switch. Sage development nowadays does not seem to
be anymore about math research and efficient computations but mostly
about "dependencies", "infrastructure" and "maintenance". I am always
depressed by reading the change logs. It might have been a reasonable
thing if sage was a "stable core Computer Algebra System" on which
further specialized math research libraries would depend on. But the
latter is not the official nor advised way of doing things.

On Thu, 8 Feb 2024 at 14:02, Michael Orlitzky  wrote:
>
> On Thu, 2024-02-08 at 11:30 +, Dima Pasechnik wrote:
> >
> > We should not try to compete, in effect, with Conda etc, yet we do. This is
> > the primary reason for slowness.
> >
>
> My personal stats for the year 2023-02-08 through 2024-02-08:
>
>   Commits: 423
>   Reviews: 38
>
> Zero of those have anything to do with mathematics.
>
> --
> 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/665f0fd945ca6301e75489e1922fb03462cda021.camel%40orlitzky.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/CAGEwAAmCkF%2Bj1XUQEuAK2B%3DD6WDT8Ejk9qrVBZ6fVvxg8H19EQ%40mail.gmail.com.

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

On Mon, Feb 12, 2024 at 6:02 PM Matthias Koeppe 
wrote:
>
> On Monday, February 12, 2024 at 3:18:05 AM UTC-8 Dima Pasechnik wrote:
>
> > Pinning packages to a set of tested working versions is a standard
practice, and as a matter of fact part of best practices to achieve
stability in various deployment situations, reproducibility, etc.
> >
> > In the Python world, such pinning is done using requirements.txt,
Pipfile.lock, and environment.yml files.
> > In the Sage distribution, we pin using package-version.txt and tiny
requirements.txt files.
>
> as well as install-requires.txt and spkg-configure.m4 - they also in
> some cases pin versions, strictly,or not.
>
>
> These files serve a different purpose. They declare acceptable version
ranges.

requirements.txt might as well specify the range, and this is used too e.g.

build/pkgs/phitigra/requirements.txt has

phitigra>=0.2.6

So this is all blurred and confusing

> In pure Python packages, this exists as well, as you know.
> It is done in pyproject.toml "dependencies" (previously setup.cfg/py
"install-requires").
>
> Talking about these here is a distraction that does not serve the
discussion of this topic.
>
> Now, at last, tell us what makes Sage so special that we must vendor
> sphinx and jupyter [...]
>
>
> Note that I have not expressed much of an opinion yet on your proposal.
> We'll get there.
>
> But as I have pointed out several times previously, you are using the
word "vendoring" in a polemic and idiosyncratic way, which does not serve
the discussion. More below.
>
> > A question to ask is what tooling is available to update the version
pins, and what the cost of using the tools is. For a typical upgrade, by
improving our tooling, we have reduced the work to just typing "./sage
-package update-latest sphinx --commit". In the Sphinx upgrade,
https://github.com/sagemath/sage/pull/37129/files (needs review), I ended
up updating 25 packages, so I had to use a command like this 25 times. It's
repetitive, maybe it takes 20 minutes total, but it's not remotely
something that I would use the phrase "Sage has shot itself in the foot"
for.
>
> The whole thing of a zillion vendored packages [...]
>
>
> 1. Sage does not "vendor". What is in build/pkgs is _metadata_. It's just
text. Sage _pins_ versions of packages, so there is information on the
version.

of course, I never said that metadata is vendoring, it's certainly not, and
this is a deviation from the topic.

>
> 2. Also the large Sage source tarball does not "vendor". It is a shipment
of a distribution. Distributions don't "vendor". It's the job of a
distribution to ship its components.
This is not correct. Sage is not a distribution, and  I am using the verb
as described here:  https://en.wiktionary.org/wiki/vendor#Verb

*vendor* (third-person singular simple present *vendors*, present
participle *vendoring*, simple past and past participle *vendored*)

1. (transitive
, software
engineering ) To
bundle third-party  dependencies
 with the source code
 for one's own program.
*  I distributed my application with a vendored copy of
Perl so that it wouldn't use the system copies of Perl where it is
installed.*

   1. (transitive
   , software
   engineering ) As
   the software vendor, to bundle one's own, possibly modified version of
   dependencies  with a
   standard program. *Strawberry Perl contains vendored copies of some CPAN
   modules, designed to allow them to run on Windows.*

According to this definition, everything in upstream/ is vendored (except
our own packages, like configure.)


>
> --
> 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/e2fd4a63-c029-4c1a-92eb-4a81c3ac6a16n%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/CAAWYfq1U%3DjrpU3Yn4K%2BX9kpm7p%3DENgLqch2z%2BH3ABPaK8fBU6g%40mail.gmail.com.

Re: [sage-devel] Re: One year of Sage development on GitHub

On Monday, February 12, 2024 at 10:06:59 AM UTC-8 David Lowry-Duda wrote:

On 22:42 Sun 11 Feb 2024, Matthias Koeppe wrote: 
>*2. Is our community aware of the sagemath/sage GitHub wiki?* 
>https://github.com/sagemath/sage/wiki 
>- Are the contents of the wiki front page useful? 

I think the existence of two wikis (i.e. the github wiki and 
https://wiki.sagemath.org/) is confusing.

I agree, and that one needs a separate account to edit 
https://wiki.sagemath.org/ is also unnecessary friction.

https://github.com/sagemath/sage/issues/33725 has a detailed discussion for 
possible ways of resolving this, please take a look.

-- 
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/4c5c89f0-a4e7-49e8-8be0-4e70eef7cc7dn%40googlegroups.com.

Re: [sage-devel] Re: One year of Sage development on GitHub

On Mon, Feb 12, 2024 at 6:06 PM David Lowry-Duda  wrote:
>
> On 22:42 Sun 11 Feb 2024, Matthias Koeppe wrote:
> >*2. Is our community aware of the sagemath/sage GitHub wiki?*
> >https://github.com/sagemath/sage/wiki
> >- Are the contents of the wiki front page useful?
>
> I think the existence of two wikis (i.e. the github wiki and 
> https://wiki.sagemath.org/) is confusing.

that's due to the Great GitHub Schism

>
> - DLD
>
> --
> 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/ZcpeOwLOBAUzDUOL%40icerm-dld.

-- 
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/CAAWYfq2g1T0cKO7C-SKQdQyKm1%3DDO-yj2YmA8rK6QDH8oNaCiA%40mail.gmail.com.

Re: [sage-devel] Re: One year of Sage development on GitHub

2024-02-12 Thread David Lowry-Duda


On 22:42 Sun 11 Feb 2024, Matthias Koeppe wrote:

*2. Is our community aware of the sagemath/sage GitHub wiki?*
https://github.com/sagemath/sage/wiki
- Are the contents of the wiki front page useful?


I think the existence of two wikis (i.e. the github wiki and 
https://wiki.sagemath.org/) is confusing.

- DLD

--
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/ZcpeOwLOBAUzDUOL%40icerm-dld.

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

On Monday, February 12, 2024 at 3:18:05 AM UTC-8 Dima Pasechnik wrote:

> Pinning packages to a set of tested working versions is a standard
practice, and as a matter of fact part of best practices to achieve
stability in various deployment situations, reproducibility, etc.
>
> In the Python world, such pinning is done using requirements.txt,
Pipfile.lock, and environment.yml files.
> In the Sage distribution, we pin using package-version.txt and tiny
requirements.txt files.

as well as install-requires.txt and spkg-configure.m4 - they also in
some cases pin versions, strictly,or not.

These files serve a different purpose. They declare acceptable version
ranges.
In pure Python packages, this exists as well, as you know.
It is done in pyproject.toml "dependencies" (previously setup.cfg/py
"install-requires").

Talking about these here is a distraction that does not serve the
discussion of this topic.

Now, at last, tell us what makes Sage so special that we must vendor
sphinx and jupyter [...]

Note that I have not expressed much of an opinion yet on your proposal.
We'll get there.

But as I have pointed out several times previously, you are using the word
"vendoring" in a polemic and idiosyncratic way, which does not serve the
discussion. More below.

> A question to ask is what tooling is available to update the version
pins, and what the cost of using the tools is. For a typical upgrade, by
improving our tooling, we have reduced the work to just typing "./sage
-package update-latest sphinx --commit". In the Sphinx upgrade,
https://github.com/sagemath/sage/pull/37129/files (needs review), I ended
up updating 25 packages, so I had to use a command like this 25 times. It's
repetitive, maybe it takes 20 minutes total, but it's not remotely
something that I would use the phrase "Sage has shot itself in the foot"
for.

The whole thing of a zillion vendored packages [...]

1. Sage does not "vendor". What is in build/pkgs is _metadata_. It's just
text. Sage _pins_ versions of packages, so there is information on the
version.

2. Also the large Sage source tarball does not "vendor". It is a shipment
of a distribution. Distributions don't "vendor". It's the job of a
distribution to ship its components.

--
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/e2fd4a63-c029-4c1a-92eb-4a81c3ac6a16n%40googlegroups.com.

[sage-devel] Re: Question about coercion model

2024-02-12 Thread Nils Bruin



On Monday 12 February 2024 at 03:21:36 UTC-8 Gareth Ma wrote:

sage: class Number:
: def __init__(self, x): self.x = x
: def __repr__(self): return f"Number({self.x})"
: def _acted_upon_(self, other, _): return Number(self.x * 
ZZ(other))


I think that would have horrible side effects. With that code and your 
proposed change, I think

"100" * a

should succeed and hence lead to the discovery (and caching!) of an action 
of "str" on "Number". I would expect that _acted_upon_ should be pretty 
sure of the objects it handles and not rely on generic "try and convert 
this" operations.

Another place where Parent may be needed is in the caching code itself: 
some of it happens in (partially weak) global dictionaries, but some of it 
happens *on the parent*. So `int` would probably fail to have the 
appropriate infrastructure for caching.

-- 
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/a7ae43b1-d186-4ca1-a754-c669eec7b6e5n%40googlegroups.com.

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

2024-02-12 Thread Georgi Guninski

There is discussion about this on mathoverlow [1]:

The closed form of `sum(1/factorial(n**2),n,1,oo)` doesn't appear
correct and it contradicts numerical computations, including verification
with mpmath.

Session:

sage: import mpmath
sage: su4=sum(1/factorial(n**2),n,1,oo);su4
hypergeometric((1,), (-I + 1, I + 1, -I*sqrt(2) + 1, I*sqrt(2) + 1), 1)
sage: CC(su4)
1.17227289255719 - 7.88860905221012e-31*I
sage: mpmath.hyper((1,), (-I + 1, I + 1, -I*sqrt(2) + 1, I*sqrt(2) + 1), 1)
mpc(real='1.1722728925571919', imag='-6.9025329206838533e-31')
sage: su5=sum(1/factorial(i**2) for i in range(1,100))
sage: CC(su5)
1.04166942239864

sage: mpmath.nsum(lambda n:  1/mpmath.gamma(1+n**2),[1,mpmath.inf])
mpf('1.0416694223986369')


[1]:  
https://mathoverflow.net/questions/463964/factorial-series-jd-sum-n-1-infty-frac1nd-and-hypergeometric-fu

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

[sage-devel] Re: One year of Sage development on GitHub

2024-02-12 Thread 'Martin R' via sage-devel

Found the page: 
https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md

On Monday 12 February 2024 at 14:18:12 UTC+1 Martin R wrote:

> I suggest to remove "no dark arts required", because, at least to me, many 
> of the issues I struggle with actually do require very little knowledge of 
> mathematics but a considerable amount of knowledge of the way sage works.
>
> Apart from that, I was looking for the tutorial telling me how to convert 
> a trac branch into a github PR, it would be good to have it around.
>
> Finally, "*Explore* the open meta-tickets on larger tasks 
> 
>  
> or topical pages on Algebra 
> , Coding Theory 
> , Combinatorics 
> , Manifolds 
> , Optimization 
> , Polyhedral Geometry 
> , Symbolics 
> ." leads to non existing 
> pages for Coding theory, Polyhedral Geometry 
>  and 
> Combinatorics.  I don't know whether these pages exist, but I am also 
> slightly sceptical whether there is anybody keeping them up-to-date if they 
> do.  In general, I think that labelling hygiene is a better way to achieve 
> the same goal.
>
> I really like the quick link to pull requests that  involve me!
>
> Best wishes,
>
> Martin
>
> On Monday 12 February 2024 at 07:42:55 UTC+1 Matthias Koeppe wrote:
>
>> On Thursday, February 8, 2024 at 10:16:58 AM UTC-8 Matthias Koeppe wrote:
>>
>> *2. Is our community aware of the sagemath/sage GitHub wiki?* 
>> https://github.com/sagemath/sage/wiki
>> - Are the contents of the wiki front page useful?
>>
>>
>> Meanwhile I have edited it a bit to offer "suggested activities".
>> (This is based on a version of the Trac wiki front page just before the 
>> transition to GitHub.)
>>
>> [image: Screenshot 2024-02-11 at 10.40.35 PM.png]
>>
>>  
>>
>

-- 
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/774454df-3b71-47b9-8a4f-1de78e487422n%40googlegroups.com.

[sage-devel] Re: One year of Sage development on GitHub

2024-02-12 Thread 'Martin R' via sage-devel

I suggest to remove "no dark arts required", because, at least to me, many 
of the issues I struggle with actually do require very little knowledge of 
mathematics but a considerable amount of knowledge of the way sage works.

Apart from that, I was looking for the tutorial telling me how to convert a 
trac branch into a github PR, it would be good to have it around.

Finally, "*Explore* the open meta-tickets on larger tasks 

or topical pages on Algebra , 
Coding Theory , 
Combinatorics , 
Manifolds , Optimization 
, Polyhedral Geometry 
, Symbolics 
." leads to non existing 
pages for Coding theory, Polyhedral Geometry 
 and 
Combinatorics.  I don't know whether these pages exist, but I am also 
slightly sceptical whether there is anybody keeping them up-to-date if they 
do.  In general, I think that labelling hygiene is a better way to achieve 
the same goal.

I really like the quick link to pull requests that  involve me!

Best wishes,

Martin

On Monday 12 February 2024 at 07:42:55 UTC+1 Matthias Koeppe wrote:

> On Thursday, February 8, 2024 at 10:16:58 AM UTC-8 Matthias Koeppe wrote:
>
> *2. Is our community aware of the sagemath/sage GitHub wiki?* 
> https://github.com/sagemath/sage/wiki
> - Are the contents of the wiki front page useful?
>
>
> Meanwhile I have edited it a bit to offer "suggested activities".
> (This is based on a version of the Trac wiki front page just before the 
> transition to GitHub.)
>
> [image: Screenshot 2024-02-11 at 10.40.35 PM.png]
>
>  
>

-- 
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/ee329e7e-ee8a-4f53-ba98-8ec0a5732d9bn%40googlegroups.com.

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

On Mon, Feb 12, 2024 at 12:34 PM kcrisman  wrote:
>
> As part of this thread, I'd again ask for a discussion of the following 
> situation I asked in the other thread.  Dima had some interesting points 
> about a less-vendored approach saving disk space etc., but it would be 
> helpful to have input from people who have had to install Sage in these kinds 
> of situations en masse.  Separately, I'm also wondering about the Windows 
> situation since much of the world, for better or worse, is not on Linux.

On Windows, once you have WSL 2 up and running in a default way
(something that it's very common to have, and it's beyond the scope of
Sage how to have it on in detail)
you basically are on a recent Ubuntu (assessed via a weird interface, but OK).


>
> "At least in the not too distant past there have been situations where the 
> non-requirement of internet connectivity alleviated issues of limited 
> internet accessibility in a given locale, limited download speeds, limited 
> grid electricity, etc.   This policy just as much affects those situations, 
> and perhaps some people who have installed Sage in such environments 
> (including Sage Days and other events) might want to weigh in on that, and 
> whether such situations still obtain (as I personally assume they must 
> certainly do).  I figure three-letter agencies have people with the skills to 
> get around not using pip install, but if your downloads are over a mobile 
> network (or, for that matter, Project Kuiper or Starlink or whatever), you 
> might still want to download Sage - especially now that we don't have binary 
> installs "provided"."
>
> --
> 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/1c003881-c1c5-4d5a-8fd3-fb78d46263f7n%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/CAAWYfq0_-sKSB5k4yrO-E%3DqAuOrAR6kW2HBcE30jsUGisH4ojQ%40mail.gmail.com.

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

2024-02-12 Thread kcrisman

As part of this thread, I'd again ask for a discussion of the following 
situation I asked in the other thread.  Dima had some interesting points 
about a less-vendored approach saving disk space etc., but it would be 
helpful to have input from people who have had to install Sage in these 
kinds of situations en masse.  Separately, I'm also wondering about the 
Windows situation since much of the world, for better or worse, is not on 
Linux.

"At least in the not too distant past there have been situations where the 
non-requirement of internet connectivity alleviated issues of limited 
internet accessibility in a given locale, limited download speeds, limited 
grid electricity, etc.   This policy just as much affects those situations, 
and perhaps some people who have installed Sage in such environments 
(including Sage Days and other events) might want to weigh in on that, and 
whether such situations still obtain (as I personally assume they must 
certainly do).  I figure three-letter agencies have people with the skills 
to get around not using pip install, but if your downloads are over a 
mobile network (or, for that matter, Project Kuiper or Starlink or 
whatever), you might still want to download Sage - especially now that we 
don't have binary installs "provided"."

-- 
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/1c003881-c1c5-4d5a-8fd3-fb78d46263f7n%40googlegroups.com.

[sage-devel] Question about coercion model

2024-02-12 Thread Gareth Ma


Hi all,

I am currently torturing myself by looking at the coercion model. I saw 
this line 
 
which I have questions about, in particular about its interaction with 
Python objects. Take the following code for example:


sage: class Number:
: def __init__(self, x): self.x = x
: def __repr__(self): return f"Number({self.x})"
: def _acted_upon_(self, other, _): return Number(self.x * 
ZZ(other))

: a = Number(5)
: a
: a * ZZ(3)
: a * int(3)
Number(5)
Number(15)


It goes through the coercion model and arrives at the line I linked to, 
where Y is `ZZ` in the first case and `int` in the second. Then the 
`int` fails because the `isinstance(Y, Parent)` call fails, whereas the 
first succeeds.


My question is whether this behaviour is desirable, and whether there is 
any reason why Sage doesn't also check for actions with Python objects. 
More directly, will adding a check for say `or (isinstance(Y, type) and 
Y != type)` directly break anything conceptually?


For a more realistic example, currently multiplying an elliptic curve 
point by a Python `int` uses a slow binary addition method, whereas 
multiplying by a Sage `Integer` uses an optimised pari call, due to the 
behaviour.


--
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/7fd704a3-bccf-4ef5-9862-fdce2b9d95b8%40gmail.com.

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

On Mon, Feb 12, 2024 at 12:57 AM Matthias Koeppe
 wrote:
>
> On Sunday, February 11, 2024 at 3:34:46 PM UTC-8 Dima Pasechnik wrote:
>
> On 11 February 2024 22:47:24 GMT, Matthias Koeppe  
> wrote:
> >On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote:
> >
> >I'll make an attempt to quantify this cost
> >
> >Here's an illustration of the workflow for making python_build a standard
> >"wheel" package, as proposed in
> >https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc:
>
> What you outlined is the initial one-time cost.
>
>
> That's correct, that's what I did in that post.
>
>
> There is also a cost of maintenance, which eventually gets bigger than the 
> initial cost: the thing gets outdated, its dependencies get outdated, this 
> all requires updates, tests, conflict resolutions ---something that you get 
> largely for free if you let go of the package dependency micromanagement, 
> relying instead on the Python universe out there to do the job.
>
>
> That's where a possible sleight of hand happens.
> Let's please do this discussion at normal speed, giving the audience a chance 
> to observe the facts and form their opinion.
>
> Pinning packages to a set of tested working versions is a standard practice, 
> and as a matter of fact part of best practices to achieve stability in 
> various deployment situations, reproducibility, etc.
>
> In the Python world, such pinning is done using requirements.txt, 
> Pipfile.lock, and environment.yml files.
> In the Sage distribution, we pin using package-version.txt and tiny 
> requirements.txt files.

as well as install-requires.txt and spkg-configure.m4 - they also in
some cases pin versions, strictly,or not.
Now you can lament about the lack of more developers joining the
project... (they come, they see the insanity of controlling versions
in 5 different somewhat incompatible ways, they leave).

>
> When updating the pins, testing is always necessary; it does not come for 
> free. Yes, we have our automatic tests, but in two of the examples that you 
> mentioned, Sphinx and Jupyter, some manual inspection is necessary.

Now, at last, tell us what makes Sage so special that we must vendor
sphinx and jupyter (and pytest (proposed), and tox, and...), unlike,
say, sympy, or scipy?
I imagine they spend developers' time on something more productive
than repeating the work done elsewhere, no?

>
> A question to ask is what tooling is available to update the version pins, 
> and what the cost of using the tools is. For a typical upgrade, by improving 
> our tooling, we have reduced the work to just typing "./sage -package 
> update-latest sphinx --commit". In the Sphinx upgrade, 
> https://github.com/sagemath/sage/pull/37129/files (needs review), I ended up 
> updating 25 packages, so I had to use a command like this 25 times. It's 
> repetitive, maybe it takes 20 minutes total, but it's not remotely something 
> that I would use the phrase "Sage has shot itself in the foot" for.

The whole thing of a zillion vendored packages makes Sage uniquely
hard to package, and use outside of its own venv. These 25 packages
just don't need our version micromanagement, it's already done outside
of the project.
Can we please start to let go of this "vendor everything" mentality? Please?


>
> (Our tooling for "pip" packages is actually worse than that; "./sage -package 
> update-latest" does not support them, an easy to implement wishlist item. 
> Being able to run "sage -pip install -U sphinx", then test, then updating the 
> pinned versions according to "./sage -pip freeze" -- also that's an easy to 
> implement wishlist item.)
>
> --
> 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/7f062b45-a5b3-49de-83e1-4f2f47eb96c2n%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/CAAWYfq3AufJ0470DA1WYkCZd5eAcW7nwMC6eUhtLpjoMy91TDQ%40mail.gmail.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements