Add mathics3

[mkoeppe]

Template A: Checklist for adding a package

Pre-submission Checks

• Package requires building for emscripten-wasm32 platform (not a noarch package), in other words, the package requires compilation.

Recipe Structure

Added recipes/recipes_emscripten/[package-name]/recipe.yaml with proper structure:

• context section with version (and optionally name)
• package section with name and version using Jinja2 templates
• source section with:
  • Source URL is valid and points to archive file (.tar.gz, .tar.bz2, .tar.xz, .tgz, or .zip)
  • Source URL contains ${{ version }} template for version updates
  • SHA256 hash is correct (verified with curl -sL <url> | sha256sum)
  • Patches (if any) are included in [package-name]/patches/ directory
• build section with appropriate script/method
  • Python packages: ${PYTHON} -m pip install . ${PIP_ARGS}
  • R packages: $R CMD INSTALL $R_ARGS .
  • C++ packages: Uses emcmake/emmake or emconfigure/emmake
  • Rust packages: Uses rust-nightly and maturin or appropriate Rust build tool
  • Build number is 0
  • If the script is longer than 3 lines, a build.sh is included
• requirements section (build, host, run as needed)
• tests section
  • Python packages: test_import_[package].py file created and referenced
  • C++ packages: Test executable or package_contents test
  • R packages: Package contents test
• about section with license, homepage, summary

---

PR Formatting

• PR title follows format: Add [package-name] or Update [package-name] to [version]
• PR description includes:
  • Version being added/updated
  • Any special build considerations or patches applied

Package Details

• Package Name: mathics3
• Version: 10.0.1

Build Notes

FYI @rocky @mmatera

[mmatera]

LGTM

[mkoeppe]

• Package requires building for emscripten-wasm32 platform (not a noarch package), in other words, the package requires compilation.

Actually I'm unclear about this part. It seems there are no architecture-dependent parts in this package when I build it here, but the packages in conda-forge are architecture dependent; see also conda-forge/mathics3-feedstock#27 (comment)

[mkoeppe]

OK, now it's Cythonizing

  ├─ lib/python3.13/site-packages/mathics/core/expression.cpython-313-wasm32-emscripten.so (489.68 KiB) [prefix:bin]

[rocky]

OK, now it's Cythonizing

For what it's worth, I think the introduction of Cython was a mistake, or maybe wishful thinking that Cython would somehow compensate for architectural flaws and lack of understanding or thought of what is needed.

I've never seen any compelling evidence to suggest that Cython significantly improves performance, which I guess is what it is supposed to do. And overall, it has been a source of breakage, if not also complexity.

But so be it. I guess I'm glad it's working now.

[mkoeppe]

Well if the conda-forge package is changed to architecture-independent, then I can just close this PR because those packages can be used directly in jupyterlite. conda-forge/mathics3-feedstock#27 (comment)

[mkoeppe]

With conda-forge/mathics3-feedstock#30 merged, this PR is no longer needed. Thanks @mmatera @rocky

[mkoeppe]

However,

%mamba install mathics3
mambajs 0.21.4

Specs: xeus-python, ipycanvas, ecl, fricas0-ecl, frobby, lrcalc-python, nauty, networkx, normaliz, numpy, pari, python-igraph, pyscipopt, scipy, singular, passagemath-categories, passagemath-cddlib, passagemath-cliquer, passagemath-cmr, passagemath-combinat, passagemath-environment, passagemath-flint, passagemath-glpk, passagemath-graphs, passagemath-gsl, passagemath-highs, passagemath-iml, passagemath-m4ri-m4rie, passagemath-modules, passagemath-nauty, passagemath-ntl, passagemath-objects, passagemath-plot, passagemath-polyhedra, passagemath-ppl, passagemath-rankwidth, passagemath-qepcad, passagemath-repl, passagemath-symbolics, passagemath-tdlib, passagemath-topcom, topcom, pexpect, mathics3
Channels: emscripten-forge-4x, conda-forge

Solving environment...
Cannot solve the request because of: mathics3 * cannot be installed because there are no viable options:
└─ mathics3 10.0.1 would require
   └─ python-magic *, which cannot be installed because there are no viable options:
      └─ python-magic 0.4.27 | 0.4.27 | 0.4.27 | 0.4.27 | 0.4.27 would require
         └─ libmagic *, for which no candidates were found.

[mkoeppe]

So an emscripten-forge recipe for libmagic is needed

[mkoeppe]

https://github.com/conda-forge/file-feedstock/blob/main/recipe/recipe.yaml

[mmatera]

Shall we create one?

[mkoeppe]

Yes, let's!

[mmatera]

Yes, let's!

conda-forge/staged-recipes#34252

[mmatera]

Python-magic already exists on conda-forge, and works. Maybe what is needed is lib-magic in emscript...

[mkoeppe]

Yes, exactly. libmagic is compiled code, so this needs a package in emscripten-forge

[mkoeppe]

I have libmagic ready in #5991

[mkoeppe]

Looking at https://github.com/ahupp/python-magic/blob/master/magic/loader.py, the python-magic from conda-forge will not magically work though