On 2023-05-28 16:20:02, Dima Pasechnik wrote:
>
> indeed, https://github.com/sagemath/sage/issues/29023 is the meta-ticket to
> oversee this process. Needless to say this needs more effort.
I'm sure it's out of date for boring reasons, but the branch from
29665 worked great:
https://github.com/sa
On Sun, May 28, 2023 at 4:31 PM Matthias Koeppe
wrote:
>
> On Sunday, May 28, 2023 at 8:20:18 AM UTC-7 Dima Pasechnik wrote:
>
> On Sun, 28 May 2023, 15:43 Matthias Koeppe, wrote:
>
> On Sunday, May 28, 2023 at 3:31:07 AM UTC-7 Dima Pasechnik wrote:
>
> [...] we are trying to move to using
> unve
On Sunday, May 28, 2023 at 10:01:41 AM UTC-7 Tobias Diez wrote:
I can also point at the already existing possibility to use Conda's Python
packages on a Conda-based install.
This mode of installation (
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependen
I can also point at the already existing possibility to use Conda's Python
packages on a Conda-based install.
This mode of installation (
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental)
bypasses the Sage dis
On Sunday, May 28, 2023 at 8:20:18 AM UTC-7 Dima Pasechnik wrote:
On Sun, 28 May 2023, 15:43 Matthias Koeppe, wrote:
On Sunday, May 28, 2023 at 3:31:07 AM UTC-7 Dima Pasechnik wrote:
[...] we are trying to move to using
unvendored Python packages,
i.e. these that come with "system Python", wh
On Sun, 28 May 2023, 15:43 Matthias Koeppe,
wrote:
> On Sunday, May 28, 2023 at 3:31:07 AM UTC-7 Dima Pasechnik wrote:
>
> [...] we are trying to move to using
> unvendored Python packages,
> i.e. these that come with "system Python", where the latter refers to
> the unvendored Python used by Sag
On Sunday, May 28, 2023 at 3:31:07 AM UTC-7 Dima Pasechnik wrote:
[...] we are trying to move to using
unvendored Python packages,
i.e. these that come with "system Python", where the latter refers to
the unvendored Python used by Sage
instead of its own Python3
Would you mind elaborating wh
On Fri, May 26, 2023 at 6:15 PM Oscar Benjamin
wrote:
>
> On Fri, 26 May 2023 at 16:19, William Stein wrote:
> >
> > On Fri, May 26, 2023 at 7:57 AM wrote:
> > > > a) Sage has a dual role as a library ("project") and as a distribution.
> > > > NEP
> > > > 29 was designed for projects, and not f
> a) Sage has a dual role as a library ("project") and as a distribution.
NEP 29 was designed for projects, and not for software distributions.
What problems do you see that come from sage having aspects of a software
distribution?
"Sage-the-distribution" allows us to reduce the inconvenien
I'd like to stress one important point already made : dropping support for
old/antique/paleontologic versions of Python lightens the maintainance
workload of the *small* team of Sage developpers.
Given the size and the state of this team, this point should *not* be taken
lightly...
I'd also li
On Fri, 2023-05-26 at 18:15 +0100, Oscar Benjamin wrote:
>
> What is wrong with Sage just saying that an older version of an
> operating system only works with an older version of Sage?
Matthias alluded to this when he mentioned that we only have one
release branch of sage. Our version numbers ar
On Friday, May 26, 2023 at 9:19:52 AM UTC-7 Dima Pasechnik wrote:
On Fri, May 26, 2023 at 5:01 PM Matthias Koeppe
wrote:
> > d) In contrast, our uses of NumPy/SciPy in the Sage library are very
basic
> > and dating back by about a decade;
> No, not true. E.g.
> schemes/riemann_surfaces/riem
On Fri, 26 May 2023 at 16:19, William Stein wrote:
>
> On Fri, May 26, 2023 at 7:57 AM wrote:
> > > a) Sage has a dual role as a library ("project") and as a distribution.
> > > NEP
> > > 29 was designed for projects, and not for software distributions.
> >
> > No, Sage is just a project, with l
> I have the impression that NEP 29 tried to very
rigidly define end of life by a specific timeline with no flexibility
for the potential that the official Python release timelines are not
rigid and fixed in stone forever
The PR linked above mentions quite often that they do take
variations/c
Here is the PR that introduced NEP 29:
https://github.com/numpy/numpy/pull/14086. The main discussion happened in
person at scipy 2019 and in webcalls. But a lot of the points raised here
are answered in this PR.
For example, the point about Linux LTS / Python EOL is addressed by one of
the wr
On Fri, May 26, 2023 at 9:19 AM Dima Pasechnik wrote:
> Please admit it, otherwise. I don't see a way to continue a discussion with
> you.
Can you please continue to engage, but view this as a public debate
for the benefit of all sage developers, rather than a discussion with
Matthias? It's a
On Fri, May 26, 2023 at 5:01 PM Matthias Koeppe
wrote:
>
> On Friday, May 26, 2023 at 7:57:53 AM UTC-7 dim...@gmail.com wrote:
>
> On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote:
> > I am voting NO.
> >
> > I. This proposed policy change does not solve any problem. There are no
>
On Friday, May 26, 2023 at 7:57:53 AM UTC-7 dim...@gmail.com wrote:
On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote:
> I am voting NO.
>
> I. This proposed policy change does not solve any problem. There are no
> problems whatsoever with how we have managed the support of Pytho
On Fri, May 26, 2023 at 7:57 AM wrote:
> > a) Sage has a dual role as a library ("project") and as a distribution. NEP
> > 29 was designed for projects, and not for software distributions.
>
> No, Sage is just a project, with lots of dependencies (way too many).
> It's not a software distribution
Hi,
To help with people who want to make an informed decision, is there
any public discussion of the original NEP 29 proposal?
The only thing I could find was this post from Sebastian Berg, where he says at
https://mail.python.org/pipermail/numpy-discussion/2019-October/080128.html
"We propose
On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote:
> Thanks, Tobias, for opening this vote thread. Here on sage-devel, this is a
> much better setting than what you attempted
> in https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945
>
> I am voting NO.
>
> There's a
Thanks, Tobias, for opening this vote thread. Here on sage-devel, this is a
much better setting than what you attempted
in https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945
I am voting NO.
There's a simple rationale:
I. This proposed policy change does not solve any problem.
22 matches
Mail list logo
