New repo: sagemath/mols-handbook-data.git

[orlitzky]

Problem Description

As part of #30914, I've created https://github.com/orlitzky/mols-handbook-data to replace the old combinatorial_designs package with something that can be detected by python.

Proposed Solution

Can I please have access to a new sagemath/mols-handbook-data.git repo to push my changes? This is required before the first release if we want the docs to point to the right place.

Alternatives Considered

N/A

Additional Information

No response

Is there an existing issue for this?

• I have searched the existing issues for a bug report that matches the one I want to file, without success.

[tornaria]

Please don't. This is just a single text file which contains a bunch of number copied from a handbook. It's not even used in sagemath, except for testing purposes.

See what I did in #37024.

[orlitzky]

Please don't. This is just a single text file which contains a bunch of number copied from a handbook. It's not even used in sagemath, except for testing purposes.

See what I did in #37024.

I looked at it yesterday. I've made a few minor improvements on top of what was there:

• Incorporated two updated lower bounds from https://site.uvm.edu/jdinitz/?page_id=389
• Added type hints that pass checks with mypy
• Added a few tests
• Commented the rows in the table so they can be compared/verified against the handbook

Like you say, this code barely belongs in sage. Why not move it out of sage? If we ever want to delete the one function that uses it (and eliminate the dependency), then our job will be that much easier: we'll be able to say "just pip install mols-handbook-data yourself!" to anyone who doesn't want to see it go.

[tornaria]

Just don't, please. There's really no need to fragment everything in separate packages just because. It's not like the file is going anywhere, even if sagemath were to drop it.

I think it's a complete waste of time (yours and others, now and in the future).

Why not have a sage-is-odd package? Node has it, and it's quite successful (https://www.npmjs.com/package/is-odd -- 200k downloads per week)

[orlitzky]

Just don't, please. There's really no need to fragment everything in separate packages just because. It's not like the file is going anywhere, even if sagemath were to drop it.

I think it's a complete waste of time (yours and others, now and in the future).

It's already a separate package, a nonstandard one that is coupled to sage but can't be discovered from within sage. The last time anyone touched this stuff was a decade ago, and the work to package it is already done. So whatever time was going to be wasted has already been wasted.

And in return, we get

• Simpler distro packages (compared to the existing database packages that are married to sage)
• Reusability outside of sage
• The ability to easily drop it as a dependency of sage in the future
• (Relative to Access database and other files through features, for simpler configuration #37024) a file filled with 10,000 integers that is touched once every ten years stays out of our source tree

Why not have a sage-is-odd package? Node has it, and it's quite successful (https://www.npmjs.com/package/is-odd -- 200k downloads per week)

Sage is already odd enough. The new package isn't tied to sage any more and would be simply is-odd, which, apparently, is quite popular. If 200,000 people wanted to look up lower bounds for mutually-orthogonal latin squares in python, that would be a great reason to make it a separate package.

[tornaria]

Just don't, please. There's really no need to fragment everything in separate packages just because. It's not like the file is going anywhere, even if sagemath were to drop it.
I think it's a complete waste of time (yours and others, now and in the future).

It's already a separate package, a nonstandard one that is coupled to sage but can't be discovered from within sage. The last time anyone touched this stuff was a decade ago, and the work to package it is already done. So whatever time was going to be wasted has already been wasted.

You are certainly entitled to waste your own time as you wish. But making a package for this will waste other people time for (IMO) no gain. Distros will have to repackage a stupid package (current combinatorial_designs) into another stupid package, with all the deprecation, replacement, etc. It's another package for which sagemath becomes upstream, another package in pypi, etc.

* Simpler distro packages (compared to the existing database packages that are married to sage)

Distro package is already there. It's just files placed somewhere. With #37024 the files can be found either in /usr/share/<DATABASE NAME> or in /usr/share/sagemath/<DATABASE NAME>, or even in /usr/local/share/sagemath/<DATABASE NAME> or even in $HOME/.sage/db/<DATABASE NAME> installed by the user if missing from the system.

This for a "real" database (e.g. cremona's database of elliptic curves which is quite big). In this case, distro package can be removed after #37024.

Nothing is simpler than nothing.

Note that the build/pkgs/combinatorial directory uses more storage blocks than the actual file (!!). Also, there are more tables/databases in sage source (src/sage/combinat/designs/database.py, src/sage/knots/knot_table.py just to name two random ones). Are you going to make a python package for each one of them? Are you going to force sagemath into being upstream for all of that?

* Reusability outside of sage

Not useful for anything. ¿Do you use it? ¿Who will use it? ¿Who will maintain it? It's just a list of numbers, let's keep it a list of numbers in a place where it's used (and tested, fwiw: how are you going to test it, sure your package will not checkdepends on sagemath).

* The ability to easily drop it as a dependency of sage in the future

It becomes a file after #37024 and one can just /bin/rm it (or git rm if you will).

* (Relative to [Access database and other files through features, for simpler configuration #37024](https://github.com/sagemath/sage/pull/37024)) a file filled with 10,000 integers that is touched once every ten years stays out of our source tree

It stays in the only place it has a chance to be useful, if any.

Why not have a sage-is-odd package? Node has it, and it's quite successful (https://www.npmjs.com/package/is-odd -- 200k downloads per week)

Sage is already odd enough. The new package isn't tied to sage any more and would be simply is-odd, which, apparently, is quite popular. If 200,000 people wanted to look up lower bounds for mutually-orthogonal latin squares in python, that would be a great reason to make it a separate package.

🤷

[orlitzky]

I've never gotten so much nothing done in my life, talk about wasted time.