Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

[Matthias Koeppe]

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

- https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_mock#spkg-pytest-mock (added in 2022)

- https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_xdist#spkg-pytest-xdist (added in 2022)

- https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build (added in 2022)

"pytest" is the current gold standard for running tests of Python packages. Various standard packages in the Sage distribution already declare pytest in "dependencies_check" as a conditional dependency for use when SAGE_CHECK=yes is set. By making pytest a standard package, I would hope to help revive the effort to make Sage compatible with pytest, largely stalled after 2022 as the main author shifted his focus to other modes of impact on Sage development. This is part of a larger effort to "adopt mainstream Python testing/linting infrastructure" (see https://github.com/sagemath/sage/issues/28936). The other pytest_* packages are related technical packages.

"python_build" (a.k.a. pypa/build) is the current standard front-end for making source distributions and wheels from a Python source tree. It has replaced the deprecated practices of calling "setup.py sdist" or "setup.py bdist_wheel" directly. We already use it for building the modularized distribution packages. Making it a standard package will allow us to modernize the build infrastructure of the Sage library. (See https://github.com/sagemath/sage/pull/35618)

[Dima Pasechnik]

yes, make them standard, but keep them pip packages (i.e. no version
pinning, no tarballs/checksums).

I'd like to see more Sage Python packages becoming pip packages, in
particular dependencies of pytest and python_build which are not
dependencies of sagelib. (Ideally, all Sage Python packages not used
by sagelib should be pip packages).

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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a49396f3-aae7-4862-8013-8e566a96ba19n%40googlegroups.com.

[Matthias Koeppe]

On Saturday, February 10, 2024 at 2:56:57 PM UTC-8 Dima Pasechnik wrote:

yes, make them standard, but keep them pip packages (i.e. no version
pinning, no tarballs/checksums).

By current policy, "standard" packages cannot be "pip" packages. This is documented in https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types

I believe the reason is that it would conflict with the longstanding practice of the project to ship Sage releases in the form of a self-contained source tarball, from which Sage can be installed in an environment without network access.

I will note that I personally never use these tarballs (nor have I recommended to anyone to use them), but historically it has been the expectation of the community. See for example the 2016 sage-devel thread https://groups.google.com/g/sage-devel/c/C7-ho1zvEYU/m/Ep8i-cbHAgAJ on a similar topic.

So for the purpose of the present poll, let us assume that the packages would be added as standard "wheel" packages. 

[Dima Pasechnik]

On 10 February 2024 23:40:59 GMT, Matthias Koeppe <matthia...@gmail.com> wrote:
>On Saturday, February 10, 2024 at 2:56:57 PM UTC-8 Dima Pasechnik wrote:
>
>yes, make them standard, but keep them pip packages (i.e. no version
>pinning, no tarballs/checksums).
>
>
>By current policy, "standard" packages cannot be "pip" packages. This is
>documented in
>https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types
>
>I believe the reason is that it would conflict with the longstanding
>practice of the project to ship Sage releases in the form of a
>self-contained source tarball, from which Sage can be installed in an
>environment without network access.

It's long overdue to revise this policy.
If someone wants to use Sage in a 3-letter agency-like environment, we need not facilitate this admittedly rare scenario, we are not in spyware tools business after all.

Besides, it is hard to create an installation medium with all the necessary extra packages on it, e.g. by downloading these missing wheels while running "make dist" (or whatever is used to create these tarballs)

How about we initiate a vote on letting standard packages be pip packages?

[Matthias Koeppe]

On Saturday, February 10, 2024 at 4:09:32 PM UTC-8 Dima Pasechnik wrote:

How about we initiate a vote on letting standard packages be pip packages?

You can make such a change of policy your project, but the present vote will not wait for it.

[William Stein]

Hi Dima,

I believe I'm the person who introduced that long standing policy. It
was indeed motivated by a significant paying customer's requirement
to install Sage entirely from source, and without an external network.
I believe no such customers have supported the Sage project for about
a decade, so I'm very supportive of removing this policy.

It's possible to install pip packages without an internet connection,
and it's also
more likely that popular published pip packages are being scanned for
vulnerabilities
regularly, than it is that a vendored version of that same package in
the sage source
distro is being scanned.

I hope you do bring this to a vote, and feel free to copy my above statement of
support.

I also strongly agree with Matthias that a vote about pip
installability may be considered
separately from a vote to add these testing packages.

-- William

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/764854CA-8AFD-4FB2-8A51-42F58BDE5D31%40gmail.com.



--
William (http://wstein.org)

[William Stein]

(Also, thanks everyone for so far taking extra effort to be civil when
discussing the topic of vendored
dependencies, which I know touches a nerve for people.)

--
William (http://wstein.org)

[kcrisman]

I believe I'm the person who introduced that long standing policy. It
was indeed motivated by a significant paying customer's requirement
to install Sage entirely from source, and without an external network.
I believe no such customers have supported the Sage project for about
a decade, so I'm very supportive of removing this policy.

However, 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".

[Dima Pasechnik]

5

Sage 10.2 tarball is 1.3Gb, of which upstream/ subdirectory takes 80%.
(for some reason there's also .git/ - something I don't get the reason for having at all, and .github/ - something that is not needed if you just want to build a full Sage).


Of upstream/, ~50% is not needed on a typical Linux system, even if you go for a lazy approach of installing from the OS a dozen of most obvious packages, such as compilers, python3, pip, etc.

On some linux systems you don't need anything in upstream at all.

We can certainly provide a list of tarballs/wheels to download to create a complete upstream/, in case of a need to have a full offline install. Tools like wget can use such a list to get the files.

Downloading in smaller chunks is more robust, by the way. And it reduces disk space requirements for the machine one uses, as well as space on the mirrors.

Keeping a package as pip package or converting it to such a package further reduces the space required on mirrors, as well as the hassle of maintaining tarballs/wheels, etc.

Dima

[Kwankyu Lee]

How about we initiate a vote on letting standard packages be pip packages?

The vote should be rather on assuming internet connectivity for sage build than on allowing standard pip packages. They are equivalent conditions. Right?

[mmarco]

Maybe you can get the best of both worlds? I mean: use those packages as pip packages, but also have a way to download a big tarball with those packages, and then pip-install them from that local copy?

[Dima Pasechnik]

no, why, you can pre-download them, and then build using local copies.


>>
>

[Matthias Koeppe]

Reminder to all to please keep the thread on topic (= vote on making these packages standard).

Focus matters!

On Sunday, February 11, 2024 at 6:21:44 AM UTC-8 Dima Pasechnik wrote:

Sage 10.2 tarball is 1.3Gb, of which upstream/ subdirectory takes 80%.
(for some reason there's also .git/ - something I don't get the reason for having at all

This one I can quickly answer: It's obviously done to make it easy to contribute any changes made in the unpacked source tree.

[Kwankyu Lee]

+1 from me to the original proposal

[Matthias Koeppe]

Open for review:

- https://github.com/sagemath/sage/pull/37301 (build/pkgs/pytest*: Change to standard normal packages)

- https://github.com/sagemath/sage/pull/37300 (build/pkgs/python_build: Make standard)

[Dima Pasechnik]

It seems you had one vote for, and one against. Is it enough to declare these packages accepted as standard now?

By the way, pytest inclusion already adds 5 standard packages, not one.

[Matthias Koeppe]

On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:

It seems you had one vote for, and one against. Is it enough to declare these packages accepted as standard now?

We haven't counted votes yet. 

(Where do you see a vote against the proposal?)

I opened the PRs so that people can look at the details, in the hope of receiving more reactions.

By the way, pytest inclusion already adds 5 standard packages, not one.

You mean "not three"?

The PR https://github.com/sagemath/sage/pull/37301 adds pytest, pytest_xdist, pytest_mock (as proposed), and their dependencies execnet and iniconfig.

[Dima Pasechnik]

On 16 February 2024 20:05:51 GMT, Matthias Koeppe <matthia...@gmail.com> wrote:
>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
>
>It seems you had one vote for, and one against. Is it enough to declare
>these packages accepted as standard now?
>
>
>We haven't counted votes yet.
>(Where do you see a vote against the proposal?)

My vote for is conditional on them remaining pip packages, and that's not what your PRs do.

>
>I opened the PRs so that people can look at the details, in the hope of
>receiving more reactions.

potentially if they are positively reviewed they become mergeable. That's why I would rather see them pending.

[Matthias Koeppe]

On Friday, February 16, 2024 at 1:25:13 PM UTC-8 Dima Pasechnik wrote:

>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
My vote for is conditional on them remaining pip packages, and that's not what your PRs do.

I'll count that as 0.

[Dima Pasechnik]

you can count that as negative reviews on your PRs
as they are now.


>

[Matthias Koeppe]

Note that posting a proposal here on sage-devel to make the packages standard followed the policies of our project. 

"optional packages stay in that status for at least a year, after which they can be proposed to be included as standard packages in Sage. For this a GitHub PR is opened with the label c: packages: standard. Then make a proposal in the Google Group sage-devel." https://doc.sagemath.org/html/en/developer/packaging.html#inclusion-procedure-for-new-and-updated-packages

Multicasting "negative reviews" to tickets is not part of the procedures of our project; cf. https://github.com/sagemath/sage/pull/36726#issuecomment-1820148873 on the emergence of this idea.

[Dima Pasechnik]

I have made it clear under what condition you can count my vote as +1.

To make it clear: it is -1 if the condition is not met.

[Tobia...@gmx.de]

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

[Matthias Koeppe]

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.

[Dima Pasechnik]

On Mon, Feb 19, 2024 at 5:31 PM Matthias Koeppe <matthia...@gmail.com> 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 unconstrained.

What does this comment have to do with the question at hand?

Package versions of standard packages at the moment  are set up in package-version.txt

files, as it clear for all to see in your own PR making pytest* into standard packages:

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

(with all the mess of checksums, tarballs/wheels, etc etc)

Pip package versions need not to be explicit, however, and one won't need to

worry about checksums, tarballs/wheels (unless installing Sage on an air-gap system...)

 

 

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 "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 Pasechnik wrote:

I have made it clear under what condition you can count my vote as +1.

To make it clear: it is -1 if the condition is not met.

On 17 February 2024 04:26:14 GMT, Matthias Koeppe <matthia...@gmail.com> wrote:

Note that posting a proposal here on sage-devel to make the packages standard followed the policies of our project. 

"optional packages stay in that status for at least a year, after which they can be proposed to be included as standard packages in Sage. For this a GitHub PR is opened with the label c: packages: standard. Then make a proposal in the Google Group sage-devel." https://doc.sagemath.org/html/en/developer/packaging.html#inclusion-procedure-for-new-and-updated-packages

Multicasting "negative reviews" to tickets is not part of the procedures of our project; cf. https://github.com/sagemath/sage/pull/36726#issuecomment-1820148873 on the emergence of this idea.

On Friday, February 16, 2024 at 4:34:12 PM UTC-8 Dima Pasechnik wrote:

On 16 February 2024 23:33:48 GMT, Matthias Koeppe <matthia...@gmail.com> wrote:
>On Friday, February 16, 2024 at 1:25:13 PM UTC-8 Dima Pasechnik wrote:
>
>>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
>My vote for is conditional on them remaining pip packages, and that's not
>what your PRs do.
>
>
>I'll count that as 0.

you can count that as negative reviews on your PRs
as they are now.


>

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0b84b09a-3a20-4a5f-91ea-f38566b33ed4n%40googlegroups.com.

[Matthias Koeppe]

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 <matthia...@gmail.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 "standard". -1 on everything ("standard pip" or "standard wheel") that involves an unnecessary version constraint and an explicit declaration of the runtime dependencies.

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.

What does this comment have to do with the question at hand?

Not sure what you're asking. I've clearly quoted what I'm responding to.

 

Package versions of standard packages at the moment  are set up in package-version.txt

files, as it clear for all to see in your own PR making pytest* into standard packages:

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

"For all to see" in the PRs also that there are the files "install-requires.txt" that I mentioned.

Their purpose is documented in our Developer Guide - https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#python-based-packages

But for convenience I'll include an explanation below.

 

(with all the mess of checksums, tarballs/wheels, etc etc)

Calling it a "mess" is not helpful for the discussion. 

I'd ask for using much more restraint in using such rhetorical devices.

Pip package versions need not to be explicit, however, and one won't need to

worry about checksums, tarballs/wheels (unless installing Sage on an air-gap system...)

In the Python (pip) world:

- Version constraints of dependencies of a Python project are declared in pyproject.toml [project] dependencies (https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#declaring-required-dependency); or, equivalently. in the older formats: setup.cfg install-requires, or setup.py install_requires

- Pinning to specific versions is done using a file "requirements.txt" (https://pip.pypa.io/en/stable/reference/requirements-file-format/)

- This file can be created and updated by using "pip freeze".

In the conda world:

- Version constraints of dependencies of a project are declared in environment.yml

- Pinning to specific versions can be done in separate environment file such as conda-lock.yml

- Updating the lock file can be done using conda-lock (https://github.com/conda/conda-lock?tab=readme-ov-file#why)

- Example in Sage: https://github.com/sagemath/sage/blob/develop/src/environment-dev-3.11-macos-arm64.yml#L329 pins "pytest=7.4.3=pyhd8ed1ab_0" and its dependency "iniconfig=2.0.0=pyhd8ed1ab_0" (https://github.com/sagemath/sage/blob/develop/src/environment-dev-3.11-macos-arm64.yml#L194)

In the Sage distribution:

- Version constraints of normal Python packages are declared in files build/pkgs/*/install-requires.txt

- Pinning to specific versions is done in the files build/pkgs/*/package-version.txt

- Updating the pins is done using "sage --package update" or "sage --package update-latest".

[Dima Pasechnik]

On Mon, Feb 19, 2024 at 7:34 PM Matthias Koeppe <matthia...@gmail.com> 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 <matthia...@gmail.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 "standard". -1 on everything ("standard pip" or "standard wheel") that involves an unnecessary version constraint and an explicit declaration of the runtime dependencies.

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.

What does this comment have to do with the question at hand?

Not sure what you're asking. I've clearly quoted what I'm responding to.

 

Package versions of standard packages at the moment  are set up in package-version.txt

files, as it clear for all to see in your own PR making pytest* into standard packages:

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

"For all to see" in the PRs also that there are the files "install-requires.txt" that I mentioned.

Their purpose is documented in our Developer Guide - https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#python-based-packages

But for convenience I'll include an explanation below.

your explanation is not very clear. E.g.  'Pinning to specific versions is done using a file "requirements.txt"'

should read 'Pinning to specific versions, or to version ranges, can be done using a file "requirements.txt"'

 

(with all the mess of checksums, tarballs/wheels, etc etc)

Calling it a "mess" is not helpful for the discussion. 

I'd ask for using much more restraint in using such rhetorical devices.

A mess is still a mess. 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 ?

By the way, "you must have missed that ..." is certainly a rhetorical, and I'd say, patronizing, device.

 

Pip package versions need not to be explicit, however, and one won't need to

worry about checksums, tarballs/wheels (unless installing Sage on an air-gap system...)

In the Python (pip) world:

- Version constraints of dependencies of a Python project are declared in pyproject.toml [project] dependencies (https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#declaring-required-dependency); or, equivalently. in the older formats: setup.cfg install-requires, or setup.py install_requires

- Pinning to specific versions is done using a file "requirements.txt" (https://pip.pypa.io/en/stable/reference/requirements-file-format/)

- This file can be created and updated by using "pip freeze".

In the conda world:

- Version constraints of dependencies of a project are declared in environment.yml

- Pinning to specific versions can be done in separate environment file such as conda-lock.yml

- Updating the lock file can be done using conda-lock (https://github.com/conda/conda-lock?tab=readme-ov-file#why)

- Example in Sage: https://github.com/sagemath/sage/blob/develop/src/environment-dev-3.11-macos-arm64.yml#L329 pins "pytest=7.4.3=pyhd8ed1ab_0" and its dependency "iniconfig=2.0.0=pyhd8ed1ab_0" (https://github.com/sagemath/sage/blob/develop/src/environment-dev-3.11-macos-arm64.yml#L194)

In the Sage distribution:

- Version constraints of normal Python packages are declared in files build/pkgs/*/install-requires.txt

- Pinning to specific versions is done in the files build/pkgs/*/package-version.txt

- Updating the pins is done using "sage --package update" or "sage --package update-latest".

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/94060e30-f224-44fd-841e-7b2060a222f1n%40googlegroups.com.

[Matthias Koeppe]

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 need to improve the explanations -- is it unclear *before* or *after* reading the documentation in https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#python-based-packages?

[Dima Pasechnik]

I don't think the docs describe the interaction between package-version.txt and install-requires.txt

(and between potential version constraints in spkg-configure.m4)




 

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/26d4ab2d-8982-47b9-8707-1ed1d29f8e0en%40googlegroups.com.

[Matthias Koeppe]

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 <matthia...@gmail.com> 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 version numbers in

package-version.txt ?

Just so I know where I need to improve the explanations -- is it unclear *before* or *after* reading the documentation in https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#python-based-packages?

I don't think the docs describe the interaction between package-version.txt and install-requires.txt

(and between potential version constraints in spkg-configure.m4)

Let's take this as an opportunity to improve the documentation where needed. 

I have opened https://github.com/sagemath/sage/pull/37401 for this, let's take the discussion there.

[Matthias Koeppe]

(Obviously I meant to say "does NOT set a version 'constraint'.)

[Matthias Koeppe]

The PR is waiting for review.

 

[Matthias Koeppe]

Much of a discussion didn't happen on that PR, but now I have added more material, salvaged from the sage-devel thread 'allow standard packages to be pip packages'. Thanks to John, Nils, Kwankyu, Nathan for the thoughtful posts over there. I'd appreciate a review of the PR and of course any further suggestion how to improve the writing. https://github.com/sagemath/sage/pull/37401/files