sagelib: Update metadata for PyPI deployment as package sagemath-standard

[mkoeppe]

We update the following items in build/pkgs/sagelib/src/:

• Add README.rst
• Add LICENSE.txt (for sagelib and documentation only - see discussion in Install COPYING.txt #21571)
• setup.py metadata (author, license, compatibility, ....)

We switch from distutils to setuptools so we can put the new metadata in the setup.cfg format.

sage-devel post regarding naming:

• https://groups.google.com/g/sage-devel/c/3mCIV9LnP9c/m/lQXLEGKcCQAJ

Naming was discussed during https://wiki.sagemath.org/days111 and a decision made to use the sagemath-... format and in particular sagemath-standard.

CC: @dimpase @jhpalmieri @mmasdeu @videlec @malb @kiwifb @embray @NathanDunfield @slel @orlitzky @fchapoton @vbraun @seblabbe @williamstein @mwageringel @saraedum

Component: build

Keywords: sd111

Author: Matthias Koeppe

Branch/Commit: 7ad4c0e

Reviewer: John Palmieri

Issue created by migration from https://trac.sagemath.org/ticket/30912

[mkoeppe]

comment:1

Currently, setup.py thinks that the name of the distribution is sage.

• sage is taken - see Claim "sage" package on PyPI, replace unexplained package "sage 0.0.0" #28796 Claim "sage" package on PyPI, replace unexplained package "sage 0.0.0"
• sagemath is taken - https://pypi.org/project/sagemath/ "This is a dummy package that checks that Sage is installed in the system"
• various other related and unrelated packages are published as sage-* - https://pypi.org/search/?q=sage

I was planning to change it to sagelib. But we could also try a systematic approach regarding branding and call it sagemath-standard (in anticipation of the modularization project's smaller distributions that could be called sagemath-core, sagemath-ntl, etc., see #29705).

[mkoeppe]

Branch: u/mkoeppe/sagelib__update_metadata_for_pypi_deployment

[mkoeppe]

New commits:

2c40179

build/pkgs/sagelib/src: Update metadata

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

Commit: 2c40179

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

2a91862

build/pkgs/sagelib/src/README.rst: Add some text

[sagetrac-git]

Changed commit from 2c40179 to 2a91862

[dimpase]

comment:5

should we also claim https://pypi.org/project/sagemath/ ?

[mmasdeu]

comment:7

The dummy package on pypi.org/project/sagemath was created so that other projects could be made to depend on it, and thus allow a user to install a custom package without having to recompile Sage. This has worked well to this day, you can install the darmonpoints package with a one-liner and alongside it checks that the installed version of Sage is the correct one.

At the time (2016 maybe?) we thought that this was a good idea, since it seemed like it was a long time until modularization would be a reality.

The dummy package only has one function (check_version) which compares the version passed as parameter with the sage version (via from sage.all import version).

I don't mind giving away this package if modularity is happening, since then there would a proper way to check for each of the required packages (there should be a way to check for the "whole sage" being installed, since it may be hard to decide on all the dependencies).

How should we go about it? I would rather have this kind of functionality (and I am assuming that the other two package maintainers that use the dummy package would be with me) available during the transition, specially if it takes more than a week or two...

[mkoeppe]

comment:8

I certainly don't need the sagemath name itself any time soon - I would use suffixed names such as sagemath-standard.

[mkoeppe]

Description changed:

--- 
+++ 
@@ -4,3 +4,5 @@
 
 We switch from distutils to setuptools so we can put the new metadata in the `setup.cfg` format. 
 
+sage-devel post regarding naming:
+- https://groups.google.com/g/sage-devel/c/3mCIV9LnP9c/m/lQXLEGKcCQAJ

[tobiasdiez]

comment:13

What's the reason that this new metadata is only in build/.../sagelib and not (also?) under src?
Other than that, the changes look good to me.

Moreover, FYI, PEP 621 for Storing project metadata in pyproject.toml has been provisionally accepted (and will be fully accepted latest on 2021-03-01). Once setuptools supports this, I would propose to follow it and put the metadata in pyproject.toml.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

6432727	Merge tag '9.3.beta2' into t/30912/sagelib__update_metadata_for_pypi_deployment
4a693f2	Move build/pkgs/sagelib/src/setup.cfg to SAGE_ROOT/src, replace by symlink
ea182d7	Copy changes from build/pkgs/sagelib/src to src

[sagetrac-git]

Changed commit from 2a91862 to ea182d7

[mkoeppe]

comment:15

Replying to @tobiasdiez:

What's the reason that this new metadata is only in build/.../sagelib and not (also?) under src?

I guess I had wanted to avoid merge conflicts with #30371, but here you go.