Re: Query on Sagemath package

[Dima Pasechnik]

Dear both,

Sorry, I didn't have time to look at it, summer is in general a quiet
time here on sagemath side.
The best option for you would be to make a regular Python package from
your library, dependent on sagelib (the python package).
There is a number of examples of such packages around, e.g.
https://github.com/thecaligarmo/oriented_matroids

There should be a list of such packages on https://www.sagemath.org -
I'll look into creating it - Harald, do you have an idea where to put
such a list of downstream Sage packages on the website?

Dima

On Wed, Jul 16, 2025 at 9:37 AM Jesus Martinez-Garcia
<je...@jesusmartinezgarcia.net> wrote:
>
> Dear Dima Pasechnik,
>
> I hope this email finds you well. I am writing to you for advice. As you may have seen, Robbie Hanson (in CC, now at Imperial) and I have completed a Sagemath library to describe Geometric Invariant Theory quotients. These play an important role in algebraic geometry and nearby fields, to describe parametrisation spaces.
>
> We wrote about it on sage-devel but didn't hear back, so I thought of writing to you for your opinion.
>
> Do you think we should open a PR (or an Issue) on Sagemath Github to ask someone to review it?
>
> If the response is positive, would it be possible to add it as an experimental/optional package? I have seen this issue about it here, but I am aware the person writing it no longer belongs to the Sagemath Project,so I am not sure if what is there is still relevant (I note it is labelled as 'open').
>
> Many thanks,
>
> Jesús

[aska...@gmail.com]

Hi,

Thanks for taking the time to look into this as I am very aware you are quite busy. 

I am relatively new to working with a project. I am not fully certain, but I think our project is exactly what you say: " a regular Python package" although I am not sure if it is "dependent on sagelib (the python package)" although it certainly uses bits from sagemath, e.g. sage.combinat.subset, sage.geometry.polyhedron, sage.modules, sage.rings.rational_field, sage.sets... and I suppose that anything that starts with "import sage.xx" is dependent on sagelib?

In writing CompGIT up we followed a lot of adm_cycles package and some advice from Frederic Chapoton. I've compared our project in github to the one you link on oriented_matroids and I think roughly the differences are as follow, although I am not sure if all them are desirable for this package, e.g. some things may be choices that made sense for oriented_matroix and that I do not understand. In any case, we are missing:

- having a 'makefile' (which we certainly could make quickly)

- a line "dependencies=["sage-package"]" in pyproject.toml (which I am not sure how needed it is),

- a dockerfile

- a tox ini file (although we don't use tox for testing, should we? we use usual doctests and the test command)

I am not sure what counts as a 'downstream' package (would ours be one?) but I think what you are referring to on the website may be this https://doc.sagemath.org/html/en/reference/spkg/#optional-packages

and I guess our package could figure under 'optional/mathematics' (I'm not sure it makes sense for it to be 'experimental' since those seem to be a list of packages from other systems that are not fully integrated with sagemath). Note also that on the same page there are "Standard packages", "Experimental Packages", "Other dependencies" and "All External Packages" and the latter seems to include at least some of the experimental packages and some of the standard ones.

If you think CompGIT could be included in one of the above lists, should we first open a PR for it or is it not necessary?

Many thanks,

Jesus

[dmo...@deductivepress.ca]

There is already a github issue for this. Please continue this discussion at #39656.