Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

+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

[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

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

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

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

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

+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

[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

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

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

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,

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

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

[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

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

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

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

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

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

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,

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.

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

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

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

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

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

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

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

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

[sage-devel] Re: Question about coercion model

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

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

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

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

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

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

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

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

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

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

[sage-devel] Question about coercion model

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

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

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

On Friday, February 9, 2024 at 10:18:45 AM UTC+9 Travis Scrimshaw wrote: I would be vague about a TypeError versus a ValueError. These are used in various ways by different authors over different periods. Helping an author in choosing the most appropriate one among sometimes confusing array

Re: [sage-devel] add transformation matrix interface for BKZ

thanks for reply. I am talking about transformation matrix interface. LLL has transformation matrix interface: LLL(delta=None, eta=None, algorithm='fpLLL:wrapper', fp=None, prec=0, early_red=False, use_givens=False, use_siegel=False, transformation=False, **kwds) if set transformation=True, we