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

On Monday, February 19, 2024 at 7:02:26 PM UTC-8 Kwankyu Lee wrote: *3. Are the labels on GitHub Issues / PRs helpful?* - Note that new contributors who are not in the Triage team cannot set/change labels! - This includes component labels, but also status labels such as "needs review". We

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

*3. Are the labels on GitHub Issues / PRs helpful?* - Note that new contributors who are not in the Triage team cannot set/change labels! - This includes component labels, but also status labels such as "needs review". We may drop "needs review" label, and start to use github "draft"

[sage-devel] Please use "Issue #" in your code comments

Hi, In https://github.com/sagemath/sage/pull/37403 we are changing how to render ":issue:" role in the documentation. For example, current By github issue #7797, there is a different implementation ... will change to By Issue #7797, there is a different implementation ... Hence,

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

On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote, responding to Dima: You said: "The difference between wheel packages vs pip packages is that the latter don't require pre-fetched wheels, and absence of the need for package (micro)management." The implication is that

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

On Monday, February 19, 2024 at 2:41:11 PM UTC-8 Dima Pasechnik wrote: On Mon, Feb 19, 2024 at 10:29 PM Matthias Koeppe wrote: An option to "./configure" could work too, except that the "bootstrap" phase already downloads the "configure" tarball into that directory. an option to ./bootstrap

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

You're right, plus I was confusing "./bootstrap -d" (which is run by "make configure") with "./bootstrap -D" which forces the download. On Monday, February 19, 2024 at 3:17:11 PM UTC-8 Matthias Koeppe wrote: > On Monday, February 19, 2024 at 3:09:55 PM UTC-8 John H Palmieri wrote: > > By the

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

On Mon, Feb 19, 2024 at 9:20 PM seb@gmail.com wrote: > > *Is it time for the next step with syncing status labels > (https://github.com/sagemath/sage/issues/35927 > )? * > > The reason this is blocked is because there is a bug in the GitHub web

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

On Monday, February 19, 2024 at 3:09:55 PM UTC-8 John H Palmieri wrote: By the way, I just cloned the Sage repo and ran "make configure", which runs `./bootstrap`. The upstream directory is empty after that. You probably have autoconf/automake/... installed. In this case, it just uses them to

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

If we keep a "configure" tarball in each separate Sage installation but they share the rest of "upstream", then we save a lot of space and a lot of downloading. A workflow like % make configure % configure --with-lots-of-options % make would be familiar and unchanged from the status quo when

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

(Obviously I meant to say "does NOT set a version 'constraint'.) On Monday, February 19, 2024 at 9:31:23 AM UTC-8 Matthias Koeppe wrote: Tobias, you must have missed that making the package standard does set a version "constraint". Those are set in "install-requires.txt" files, and in

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

On Mon, Feb 19, 2024 at 10:29 PM Matthias Koeppe wrote: > An option to "./configure" could work too, except that the "bootstrap" > phase already downloads the "configure" tarball into that directory. an option to ./bootstrap then would be logical > > Another possible direction: I've been

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

An option to "./configure" could work too, except that the "bootstrap" phase already downloads the "configure" tarball into that directory. Another possible direction: I've been thinking about creating a "./sage worktree" command, see https://github.com/sagemath/sage/issues/34744 On Monday,

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

Regarding symlinking the upstream directory: instead or in addition, what about an option to `./configure` for the location of that directory? On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote: > Prompted by the discussion of space use on the *local machines* of users >

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

On 19 February 2024 21:08:54 GMT, John H Palmieri wrote: > > >On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote: > >On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote: > >This (A and B below) has the advantage of being quite explicit. The >original proposal > >1)

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

On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote: On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote: If we convert (according to (1)) to pip packages, those still need to be downloaded, and while they may not end up in "upstream" — I don't actually know how they work

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

> *Is it time for the next step with syncing status labels (https://github.com/sagemath/sage/issues/35927 )? * The reason this is blocked is because there is a bug in the GitHub web interface that might cause confusion when labels are added or

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

On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote: On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote: This (A and B below) has the advantage of being quite explicit. The original proposal 1) allow standard packages to be pip packages 2) drop the contents of

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

On Monday, February 19, 2024 at 12:46:01 PM UTC-8 Dima Pasechnik wrote: On Mon, Feb 19, 2024 at 8:27 PM Matthias Koeppe wrote: On Monday, February 19, 2024 at 11:51:46 AM UTC-8 Dima Pasechnik wrote: The purpose of "install-requires.txt" is rather unclear, especially in presence of

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

On Mon, Feb 19, 2024 at 8:27 PM Matthias Koeppe wrote: > On Monday, February 19, 2024 at 11:51:46 AM UTC-8 Dima Pasechnik wrote: > > The purpose of "install-requires.txt" is rather unclear, especially in > presence > of "package-version.txt". What is it even doing, in the presence of hard >

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

On Monday, February 19, 2024 at 11:51:46 AM UTC-8 Dima Pasechnik wrote: The purpose of "install-requires.txt" is rather unclear, especially in presence of "package-version.txt". What is it even doing, in the presence of hard version numbers in package-version.txt ? Just so I know where I

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

On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote: > This (A and B below) has the advantage of being quite explicit. The > original proposal > > 1) allow standard packages to be pip packages > > 2) drop the contents of upstream/ from the Sage source tarballs. > > sounds explicit, but the

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

Prompted by the discussion of space use on the *local machines* of users and developers, I propose another item in addition to A and B: *C. Advertise use of "git worktree" and recommend symlinking the "upstream" directory.* For testing a new release when you have an existing clone of the

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

On Mon, Feb 19, 2024 at 7:34 PM Matthias Koeppe wrote: > On Monday, February 19, 2024 at 10:35:45 AM UTC-8 Dima Pasechnik wrote: > > On Mon, Feb 19, 2024 at 5:31 PM Matthias Koeppe > wrote: > > On Monday, February 19, 2024 at 5:47:46 AM UTC-8 tobia...@gmx.de wrote: >

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

This (A and B below) has the advantage of being quite explicit. The original proposal 1) allow standard packages to be pip packages 2) drop the contents of upstream/ from the Sage source tarballs. sounds explicit, but the more the discussion goes on, the more I feel that there are hidden

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

On Monday, February 19, 2024 at 10:35:45 AM UTC-8 Dima Pasechnik wrote: On Mon, Feb 19, 2024 at 5:31 PM Matthias Koeppe https://groups.google.com/>> wrote: On Monday, February 19, 2024 at 5:47:46 AM UTC-8 tobia...@gmx.de wrote: +1 for the one-line change of the type from "optional" to

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

On Mon, Feb 19, 2024 at 5:16 PM Matthias Koeppe wrote: > On Monday, February 19, 2024 at 5:42:08 AM UTC-8 tobia...@gmx.de wrote: > > This discussion about the need to fix the version of pytest *and its > runtime dependencies* is almost comical. > > > No, you are in the wrong thread. > > This

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

On Mon, Feb 19, 2024 at 5:31 PM Matthias Koeppe wrote: > Tobias, you must have missed that making the package standard does set a > version "constraint". Those are set in "install-requires.txt" files, and in > https://github.com/sagemath/sage/pull/37301 you can see that the packages > remain

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

Tobias, you must have missed that making the package standard does set a version "constraint". Those are set in "install-requires.txt" files, and in https://github.com/sagemath/sage/pull/37301 you can see that the packages remain unconstrained. On Monday, February 19, 2024 at 5:47:46 AM UTC-8

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

On Monday, February 19, 2024 at 5:42:08 AM UTC-8 tobia...@gmx.de wrote: This discussion about the need to fix the version of pytest *and its runtime dependencies* is almost comical. No, you are in the wrong thread. This thread is about the general policy for standard packages, not about

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

+1 for the one-line change of the type from "optional" to "standard". -1 on everything ("standard pip" or "standard wheel") that involves an unnecessary version constraint and an explicit declaration of the runtime dependencies. On Saturday, February 17, 2024 at 4:51:45 PM UTC+8 Dima

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

This discussion about the need to fix the version of pytest *and its runtime dependencies* is almost comical. We are installing and running pytest successfully since 3 years without any version requirement via pip in ci and experienced zero issues. We are also not alone in that. For example,