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

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

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

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

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

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

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

On Wednesday, June 5, 2024 at 1:38:39 PM UTC-7 David Roe wrote: On Wed, Jun 5, 2024 at 4:25 PM Matthias Koeppe wrote: And the policy exists because it was made in awareness of the limitations of "pip" packages. I see the policy you refer to here <https://doc.sagemath.org/html

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

All, please send your comments on this proposal. I hope that we can count votes here by the end of the week. On Thursday, May 30, 2024 at 3:25:08 PM UTC-7 Matthias Koeppe wrote: > We added the packages as optional "pip" packages (see > https://deploy-livedoc--sagemath.net

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

On Monday, June 3, 2024 at 12:29:14 PM UTC-7 dim...@gmail.com wrote: pytest can be kept a pip package, just promoted to standard. It cannot, per existing policy. And the policy exists because it was made in awareness of the limitations of "pip" packages. -- You received this message because

Re: [sage-devel] Re: Python version support for SymPy/Sage

On Wednesday, June 5, 2024 at 12:37:38 PM UTC-7 Oscar Benjamin wrote: On Wed, 5 Jun 2024 at 19:32, Matthias Koeppe wrote: > On Wednesday, June 5, 2024 at 5:31:30 AM UTC-7 Oscar Benjamin wrote: > > Following those specifications in coordination with other scientific > > Python

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

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

[sage-devel] Re: Python version support for SymPy/Sage

On Wednesday, June 5, 2024 at 5:31:30 AM UTC-7 Oscar Benjamin wrote: My question here is: would it be problematic for Sage if SymPy were to follow SPEC 0/NEP 29 which would mean dropping support for older Python versions more quickly? Quick answer: Probably it would not be very problematic on

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

Yes, this is well worth discussing. But note that there is one non-trivial interaction of Sage with Jupyter via the recently added Live Documentation feature (jupyter-sphinx). Already "pip install jupyter-sphinx" pulls in the Rust-based package rpds_py. On Monday, June 3, 2024 at 2:47:14 PM

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

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

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

On Monday, June 3, 2024 at 12:41:41 PM UTC-7 Michael Orlitzky wrote: On Sat, 2024-06-01 at 10:02 -0700, Matthias Koeppe wrote: > we will soon add support for installing Python packages from > platform-dependent wheels. This is needed for updating some Jupyter > components that hav

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

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)

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

upstream/pytest_mock-3.14.0-py3-none-any.whl -rw-r--r-- 1 mkoeppe staff 46108 May 22 12:48 upstream/pytest_xdist-3.6.1-py3-none-any.whl On Thursday, May 30, 2024 at 3:25:08 PM UTC-7 Matthias Koeppe wrote: I ask everyone to focus on the specifics of this proposal. In particular, I'll suggest to re

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

On Tuesday, May 28, 2024 at 12:19:42 PM UTC-7 Matthias Koeppe wrote: On Tuesday, May 28, 2024 at 1:24:17 AM UTC-7 Travis Scrimshaw wrote: Another data point: the bot is getting the size wrong too: https://github.com/sagemath/sage/pull/38105 Thanks, I've let the author know in https

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

On Friday, May 31, 2024 at 9:38:30 AM UTC-7 Dima Pasechnik wrote: frankly, I don't see anything new here. There does not have to be anything new. The proposal stands on its own merit. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

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

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

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

on other people's unlabeled Issues and PRs. Does this help at all? What labels would help people discover PRs that they would be able to review? Matthias On Friday, May 10, 2024 at 7:02:19 AM UTC-7 Matthias Koeppe wrote: FWIW, I suggested to implement this feature in https://github.com/sag

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

On Tuesday, May 28, 2024 at 1:24:17 AM UTC-7 Travis Scrimshaw wrote: Another data point: the bot is getting the size wrong too: https://github.com/sagemath/sage/pull/38105 Thanks, I've let the author know in https://github.com/sagemath/sage/pull/37262#issuecomment-2135699139 -- You

Re: [sage-devel] On backdooring open source projects

On Saturday, April 20, 2024 at 2:13:13 AM UTC-7 Matthias Koeppe wrote: On Thursday, April 18, 2024 at 11:05:52 PM UTC-7 Georgi Guninski wrote: The only sage change I see after the xz drama [] Well, here's one, waiting for review: https://github.com/sagemath/sage/pull/37726 (prepared

[sage-devel] Re: CI Is (Generally) Broken

- https://github.com/sagemath/sage/pull/37998 (revised) On Friday, May 17, 2024 at 7:58:37 PM UTC-7 Matthias Koeppe wrote: > More to review: > - https://github.com/sagemath/sage/pull/37988 > - https://github.com/sagemath/sage/pull/37902 > - https://github.com/sagemath/sage/pull/379

[sage-devel] Re: Release tour Sage 10.4

 AM UTC-7 Matthias Koeppe wrote: > All, let's prepare > https://github.com/sagemath/sage/wiki/Sage-10.4-Release-Tour; so far, we > have: > > Sage 10.4 Release Tour > <https://github.com/sagemath/sage/wiki/Sage-10.4-Release-Tour> > >- Linear algebra > &g

[sage-devel] Release tour Sage 10.4

All, let's prepare https://github.com/sagemath/sage/wiki/Sage-10.4-Release-Tour; so far, we have: Sage 10.4 Release Tour - Linear algebra -

[sage-devel] Community effort: Project templates ("cookiecutters") for Sage projects

A few years back, there were efforts to support the creation of pip-installable user packages by preparing project templates that provide some common infrastructure for building and testing etc. - https://github.com/sagemath/sage_sample - Marc Masdeu's

[sage-devel] Re: (Re-)building an inclusive SageMath community. III: Our relations to the projects that Sage depends on

On Wednesday, May 1, 2024 at 1:35:08 PM UTC-7 Matthias Koeppe wrote: [...] SageMath makes use of hundreds of *"upstream" projects: third-party, separately maintained packages* [...] https://groups.google.com/g/sage-devel/c/H8FcZD90O0Y/m/VRIRzj1sBAAJ) [...] suggested that

[sage-devel] Re: building Sage still uses some "old-style" SPKG's, causes errors

I've opened https://github.com/sagemath/sage/pull/38039 (needs review) to add a check for this in the configure phase. On Monday, May 20, 2024 at 11:28:14 AM UTC-7 Matthias Koeppe wrote: > The files that have "slash in the contents" are actually symbolic links. > > On W

Re: [sage-devel] Re: VOTE: Use "CI Fix" label for merging into continuous integration runs

This was merged in 10.4.beta6, so the "CI Fix" label can now be used. On Monday, May 6, 2024 at 11:54:51 AM UTC-7 Matthias Koeppe wrote: > I have implemented this change in > https://github.com/sagemath/sage/pull/37950, needs review. > > On Wednesday, March 20, 2024 at 1

[sage-devel] Re: building Sage still uses some "old-style" SPKG's, causes errors

The files that have "slash in the contents" are actually symbolic links. On WSL, it is important to use Linux git (not some other git that may be on your system) with the exact options as instructed in https://github.com/sagemath/sage/blob/develop/README.md#instructions-to-build-from-source

[sage-devel] Re: Build from source on Apple Silicon M3

You'll need: - https://github.com/sagemath/sage/pull/38025 - https://github.com/sagemath/sage/pull/38008 - https://github.com/sagemath/sage/pull/37919 - https://github.com/sagemath/sage/pull/38021 On Sunday, May 19, 2024 at 7:04:58 PM UTC-7 Trevor Karn wrote: > Hi all, > > I am trying to build

[sage-devel] Re: collect names of all optional arguments used in sage

I could imagine that such a reference would be valuable as an additional index to our reference manual. I would suggest to look into implementing it as a Sphinx extension (after checking whether something like this already exists). Sage already uses a custom version of the Sphinx autodoc

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

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

[sage-devel] Re: CI Is (Generally) Broken

On Wednesday, May 15, 2024 at 6:43:36 PM UTC-7 Matthias Koeppe wrote: > Yes, various parts of the CI are broken. > > Fixes for the CI ready for review: > - "Makefile, .ci/write-dockerfile.sh: Update for src/pyproject.toml after > #36982" (https://github.com/sagemath/sage/pull

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

On Friday, May 10, 2024 at 7:01:43 AM UTC-7 Dima Pasechnik wrote: It's also discouraging word, "minimal" I'm also not happy about the word "minimal", but simply because it's too close to "minor", which appears in priority labels. -- You received this message because you are subscribed to

[sage-devel] Re: CI Is (Generally) Broken

Yes, various parts of the CI are broken. Fixes for the CI ready for review: - "Makefile, .ci/write-dockerfile.sh: Update for src/pyproject.toml after #36982" (https://github.com/sagemath/sage/pull/37926) - "Update conda-lock files, rename macOS conda-lock files to match CI Conda"

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

On Wednesday, May 15, 2024 at 5:36:06 AM UTC-7 David Ayotte wrote: When you are not part of the triage team, the CI checks does not run automatically and someone with "write" permission needs to activate them. A correction: It is only CI checks for "first-time contributors" that require

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

I have a draft document at https://github.com/sagemath/sage/wiki/NumFOCUS#project-governance that could be updated to describe some of the elevated repository permissions and what functions/duties they are needed for. On Tuesday, May 14, 2024 at 6:14:22 PM UTC-7 David Roe wrote: > On Tue, May

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

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

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

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

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

On Thursday, May 9, 2024 at 2:18:41 AM UTC-7 Volker Braun wrote: +1 to the general idea of maintainers for distinct subtrees As far as the implementation, I'd rather follow a model where there is a single merge queue at the end (currently me, could be automated when the CI is stricter and

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

On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote: There are some means to reuse workflows in GitHub That's correct. They are called "reusable workflows", and I use them to provide portability testing to upstream projects of Sage. You can read about them in

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

On Wednesday, May 8, 2024 at 12:18:51 PM UTC-7 Dima Pasechnik wrote: 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, I'm pretty sure that Volker and I can figure this out; there's no

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

FWIW, I suggested to implement this feature in https://github.com/sagemath/sage/issues/37254; I'm thankful to Aman Moon for implementing this feature and Sebastian Oehms for his help with it. Obviously a metric such as the number of lines of changes is only a one-dimensional way to express

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

On Wednesday, May 8, 2024 at 6:51:49 PM UTC-7 Kwankyu Lee wrote: The command "tox -e update_docker_platforms" involves a change of the list of tested platforms. The change become effective when a beta release is made by the release manager, since the docker image files are created only at the

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

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

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

On Wednesday, May 8, 2024 at 6:20:52 AM UTC-7 julian...@fsfe.org wrote: It was a bit unclear to me how your v2 proposal is different from the initial proposal on this sage-devel thread. Maybe it's helpful to clarify that build/bin/write-dockerfile.sh was removed from the proposal and

[sage-devel] Re: command not found errors from configure

Fix in https://github.com/sagemath/sage/pull/37959 On Saturday, May 4, 2024 at 3:54:55 PM UTC-7 Marc Culler wrote: > It is disturbing when one sees "command not found" errors in a configure > script. That is what happens with 10.4.beta5. After tracing it down I > found that they are coming

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

Dear Sage developers: I include an updated proposal below, with changes brought by the merged https://github.com/sagemath/sage/pull/37841, a clarification, and updated examples). I ask everyone to focus the discussion on the specifics of the proposal. I plan to call a vote on this in a week or

Re: [sage-devel] Re: VOTE: Use "CI Fix" label for merging into continuous integration runs

I have implemented this change in https://github.com/sagemath/sage/pull/37950, needs review. On Wednesday, March 20, 2024 at 10:18:53 AM UTC-7 David Roe wrote: > This vote has passed, and I've added a "CI Fix" label > on github. I >

[sage-devel] (Re-)building an inclusive SageMath community. III: Our relations to the projects that Sage depends on

Previous posts in the series: https://groups.google.com/g/sage-devel/c/OeN8o14s6Jc/m/ChnpijP3AgAJ, https://groups.google.com/g/sage-devel/c/xBzaINHWwUQ/m/Tq17YRqOAAAJ As we all know, SageMath makes use of hundreds of *"upstream" projects: third-party, separately maintained packages* written

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

e a chance to respond to earlier. On Thursday, April 25, 2024 at 6:28:48 AM UTC-7 *Dima Pasechnik* 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. Essential components of sagelib such as GAP,

[sage-devel] Re: wasm

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

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

f pip wheel" (https://github.com/sagemath/sage/pull/35618, *needs review*) On Tuesday, April 9, 2024 at 8:44:36 PM UTC-7 Matthias Koeppe wrote: > We added python_build as an optional "pip" package (see > https://deploy-livedoc--sagemath.netlify.app/html/en/develop

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

On Thursday, April 25, 2024 at 12:17:31 AM UTC-7 Martin R wrote: On Thursday 25 April 2024 at 05:13:37 UTC+2 Matthias Koeppe wrote: On Wednesday, April 24, 2024 at 1:07:44 AM UTC-7 Martin R wrote: You mentioned several times, that discoverability is an important aspect. Do you have any

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

On Wednesday, April 24, 2024 at 8:19:03 AM UTC-7 Dima Pasechnik wrote: sage -i actually calls make, This part is true. on a makefile where everything is already set up. So no, it's not for sage -i. This part is false. Our makefiles (https://github.com/sagemath/sage/blame/develop/Makefile,

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

On Wednesday, April 24, 2024 at 6:11:23 AM UTC-7 Marc Culler wrote: 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

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

On Wednesday, April 24, 2024 at 6:48:30 AM UTC-7 Oscar Benjamin wrote: 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

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

On Wednesday, April 24, 2024 at 1:07:44 AM UTC-7 Martin R wrote: You mentioned several times, that discoverability is an important aspect. Do you have any evidence to support that? I mentioned "discoverability" in the context of how I have *named* the distributions. Wouldn't people in the

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

On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote: On 23 April 2024 18:41:34 BST, Matthias Koeppe wrote: >*$ git blame src/sage/combinat//designs/block_design.py* > >fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 65) >lazy_import('sage.libs.gap.libg

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

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

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

On Tuesday, April 23, 2024 at 8:38:13 AM UTC-7 Martin R wrote: If I understand correctly, the current proposal does not mind if some things don't work or could be replaced without too much effort. For example, Dima might have referred to the fact that OrderedPartitions.cardinality uses gap,

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

On Monday, April 22, 2024 at 2:22:36 AM UTC-7 Martin R wrote: I still don't see why you would name these distributions as you do, and why you collect them as you do. Above I explained, "I introduce these packages to create *discoverability* for potential consumers of portions of the Sage

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

On Tuesday, April 23, 2024 at 5:35:10 AM UTC-7 Kwankyu Lee wrote: I meant the sage library as a collection of mathematical modules. If a certain module did not but somehow would develop to rely on the mathematical functionality of another module, then the design of the modularization should

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

On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote: On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe wrote: Let's just go through the list of distribution packages and their dependencies for concreteness. (All depend on *sagemath-categories* and thus on the basic arithmetic

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

On Saturday, April 20, 2024 at 1:01:33 PM UTC-7 Dima Pasechnik wrote: On 20 April 2024 19:34:49 BST, Matthias Koeppe wrote: SageMath is already pip-installable. >That was one of the first deliverables of the modularization project, >completed in 2021. >See https://wiki.sag

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

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

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

On Saturday, April 20, 2024 at 1:01:33 PM UTC-7 Dima Pasechnik wrote: 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

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

On Sunday, April 21, 2024 at 2:30:15 AM UTC-7 Martin R wrote: I can imagine that it would make sense to make as much as possible into runtime dependencies - you wrote below that building the dependencies takes a lot of time. Maybe that's the core problem, I don't know. If you want to know,

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

On Tuesday, April 9, 2024 at 3:36:32 PM UTC-7 Kwankyu Lee wrote: 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

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

On Saturday, April 20, 2024 at 3:23:12 PM UTC-7 Michael Orlitzky wrote: in its current incarnation, the modularization relies heavily on the sage distribution vendoring. Conflict arises because the modularization is cited as a blocker whenever someone wants to pare down or disentangle some

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

On Saturday, April 20, 2024 at 3:01:04 PM UTC-7 kcrisman wrote: "normal Python" is not necessarily as relevant for those who would *only* want Sage, or at least mostly so. Having just another Python package might lead us to implementing powers as ** instead of ^, which would be a regression,

Re: [sage-devel] Modularization project: I. The goals

On Monday, June 12, 2023 at 4:54:21 PM UTC-7 Nathan Dunfield wrote: On Monday, June 12, 2023 at 2:58:18 PM UTC-4 Matthias Koeppe wrote: What parts of Sage does SnapPy use? Primarily the various rings/fields, including matrices over them and basic linear algebra. In the present design

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

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

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

On Friday, April 19, 2024 at 12:34:06 PM UTC-7 Martin R wrote: why do you introduce distributions sage-graphs, sage-combinat, sage-categories etc. Let's follow the link included in my previous message to my June 2023 sage-devel post https://groups.google.com/g/sage-devel/c/kiB32zP3xD4 and

Re: [sage-devel] On backdooring open source projects

On Thursday, April 18, 2024 at 11:05:52 PM UTC-7 Georgi Guninski wrote: The only sage change I see after the xz drama [] Well, here's one, waiting for review: https://github.com/sagemath/sage/pull/37726 (prepared by @faisalfakhro; I reviewed and made some minor changes) updates the

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

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. Note that the description of the PR where

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

On Friday, April 19, 2024 at 5:08:02 AM UTC-7 Martin R wrote: *> 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

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

On Friday, April 19, 2024 at 3:47:38 AM UTC-7 Michael Orlitzky wrote: On 2024-04-18 14:18:37, Matthias Koeppe wrote: > 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/p

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

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

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

David, none of this explains the misleading use of the word "unreviewed". On Thursday, April 18, 2024 at 10:47:36 AM UTC-7 David Roe wrote: > On Thu, Apr 18, 2024 at 1:43 PM Matthias Koeppe > wrote: > >> I will first note that the title of this post is

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

I will first note that the title of this post is misleading. Everything that was merged has been reviewed -- as noted, many months ago. On Thursday, April 18, 2024 at 8:54:26 AM UTC-7 David Roe wrote: > Hi all, > Sage has had a review process for over 15 years, but a combination of > recent

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

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

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

Thanks all. I consider this approved. PR https://github.com/sagemath/sage/pull/37300 is ready for review. On Tuesday, April 9, 2024 at 8:44:36 PM UTC-7 Matthias Koeppe wrote: > We added python_build as an optional "pip" package (see > https://deploy-livedoc--sagemath.net

Re: [sage-devel] (Re-)building an inclusive SageMath community. II: Recognizing and fighting abuse, bullying, disrespect

ng in person, with enough time, with a good mediator. Those differences need to be spoken out and worked on. 100 E-Mails per day will not untangle the knot, imho. And, btw, none of all the e-mails made me feel uncomfortable, just sad. Best wishes, Doris Behrendt > On 11. Apr 2024, at 22:50,

Re: [sage-devel] Re: Application for NumFOCUS affiliation of SageMath

code of conduct was last modified. >> >> There is also discussion at the bottom about Sage's governance structure, >> but I don't think that's required for an affiliated project. >> David >> >> On Tue, Mar 5, 2024 at 3:37 PM Matthias Koeppe >> wrote: >&g

[sage-devel] Re: cat: logs/install.time: No such file or directory

Fixed in https://github.com/sagemath/sage/pull/37785, please review On Saturday, April 13, 2024 at 2:08:43 PM UTC-7 David Ayotte wrote: > Hello everybody, > > I just upgraded my Sage to version 10.4.beta3, however in the install logs > I see the following message: > > cat:

[sage-devel] (Re-)building an inclusive SageMath community. II: Recognizing and fighting abuse, bullying, disrespect

Trigger Warning: In this post, I will discuss topics that can make some people uncomfortable; in particular readers who have themselves been the target of abuse, bullying, and disrespect in the past. (I apologize if I have omitted this Trigger Warning in previous posts that touched these

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

contributions on sage-devel. We are sad in taking this step, and are continuing to work privately with both Dima and Matthias to resolve this conflict. David for the sage-conduct committee On Wed, Apr 10, 2024 at 7:30 PM Matthias Koeppe wrote: Reported. On Wednesday, April 10, 2024 at 3:39:56

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

I will not respond further on this in this thread. On Thursday, April 11, 2024 at 1:15:52 PM UTC-7 Dima Pasechnik wrote: > > > On 11 April 2024 21:47:57 CEST, Matthias Koeppe > wrote: > >Once again, the workflow files in .github/workflows have to be statically > >pr

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

, 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

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

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

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

Reported. On Wednesday, April 10, 2024 at 3:39:56 PM UTC-7 Dima Pasechnik wrote: > 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

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

On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 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: There is simply no need to keep the .gitsubmodules - the only file in the main repo affected

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

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

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

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

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

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

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

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

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

On Tuesday, April 9, 2024 at 6:39:00 PM UTC-7 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

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

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)

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

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

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

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

  1   2   3   4   5   6   7   8   9   10   >