Update libngspice to 46 and inspice to 1.7.0.5

[pepijndevos]

Description

ngspice 46 removes the cppduals std::is_compound specialization that newer clang/libc++ rejected with -Winvalid-specialization, which was the error that had disabled the libngspice recipe. Bumping to 46 fixes the build natively, so re-enable the recipe (drop _disabled).

All three existing patches still apply cleanly to ngspice 46.

Bump inspice to 1.7.0.5 to match; runtime dependencies are unchanged and the NgSpiceShared API used by the tests is intact.

Type of change

• Adding a new package
• Updating an existing package
• Bug fix
• Other (please describe)

---

If there is a reasonable way to ship libngspice on pypi I might do that at some point.

aiui I'll have to wait for the next release for this to be picked up? (and for marimo to pick up that release...)

[ryanking13]

Could you please try to upstream this to inspice? Then you don't have to wait for any pyodide release. As we mentioned in our PR template, we are not actively taking new recipes updates at this point, unless there is a clear reason that the package cannot be built in their own repostories.

Edit

Oh, looks like you are the maintainer of the inspice package, in that case, why not bundle libngspice to inspice?

[pepijndevos]

Inspice doesn't bundle ngspice on any platform, it's just a pure python library. And libngspice is a shared library not a wheel so aiui you can't distribute it on pypi by itself. So I mean happy to bundle it on pypi somehow but not sure about the logistics.

I did recently make a vacask-bin package, which as the name suggests ships binaries in a thin python wrapper. But I don't think that same mechanism works for publishing a share library.

[ryanking13]

Inspice doesn't bundle ngspice on any platform, it's just a pure python library.

Well, I would say you should, if you are planning to make inspice package more platform agnostic. Maybe you can do that at least for the pyemscripten wheel that doesn't have the libngspice library in the system.

I think you can update the code that locates the libngspice to something like 1) find it from the package's .libs directory, 2) if it is not found, find it from the system lib directory.

[pepijndevos]

inspice is a generic interface package though, and it doesn't make sense to ship all the simulators it supports, especially not on other platforms where they're an apt install away.

It is within my power as a maintainer to make only wasm be a binary wheel that bundles ngspice but that seems very weird. My preference is an libngspice package that follows the vacask-bin package format that users can install as they please.

Is there a way to make a wrapper wheel that either pushes those libs onto the path, or for inspice to look into the libngspice wheel? I guess some importlib resource shenanigans should work if the package is actually somewhere on the filesystem as normal files.

[pepijndevos]

Given that I already have this working recipe, what's the easiest way to turn that into a working wheel? Ideally I'd extend it to native platforms as well at some point, so maybe I just need to bite the bullet and conver to cibuildwheel?

[agriyakhetarpal]

Possibly. You could get pretty far with the importlib shenanigans you mentioned to always find the correct location for the Python package to find the library, but cibuildwheel is the more conventional approach. We have tooling in the form of auditwheel-emscripten for repairing pyemscripten wheels for this purpose. You could also think of publishing it under the name of libngspice-wasm on PyPI, i.e., not under ngspice, though I recognise it needs more work to set up the infrastructure.

[agriyakhetarpal]

I approved the workflows in the meantime, so that we can at least see whether the builds will work, if that helps.

[ryanking13]

Is there a way to make a wrapper wheel that either pushes those libs onto the path, or for inspice to look into the libngspice wheel? I guess some importlib resource shenanigans should work if the package is actually somewhere on the filesystem as normal files.

Yeah, I think that is possible. There is a scipy-openblas64 that does a similar thing. It is a python package but it only contains a shared libraries in it (with some optional helper scripts that helps finding and loading the shared libraries).

I think what you need to do is

1. copy the script that builds libngspice in the recipe file
2. create a Python package (maybe just a pyproject.toml file), with a very thin setup.py file that builds and copies the libngspice into the src directory.
3. update inspice to locate the libngspice from the site-packages directory as all the python packages will be installed there

[pepijndevos]

fopen("/proc/meminfo"): No such file or directory
Error: realloc: can't allocate 2147483648 bytes.
Not enough memory or heap corruption
Error: ngspice.dll cannot recover and awaits to be reset or detached

that is some wild error... any pyodide/emscripten change comes to mind that could cause something like that?

[github-actions]

Package Build Results

Total packages built: 48
Total build time: 0:25:58

Package Build Times (click to expand)

Package	Build Time
libngspice	21m 58s
libhdf5	17m 43s
scipy	11m 25s
libopenblas	10m 25s
libblis	5m 18s
numpy	4m 39s
libboost	4m 0s
h5py	3m 12s
matplotlib	2m 19s
libwebp	1m 46s
libtiff	1m 35s
Pillow	1m 26s
contourpy	1m 21s
kiwisolver	52s
libf2c	32s
libzlib	23s
pyyaml	19s
cffi	19s
regex	18s
MarkupSafe	10s
pydoc_data	7s
libyaml	5s
packaging	5s
atomicwrites	4s
pycparser	4s
more-itertools	3s
python-dateutil	3s
attrs	2s
pytz	2s
setuptools	2s
inspice	2s
fonttools	2s
pytest-asyncio	2s
pyparsing	2s
diskcache	2s
iniconfig	2s
pluggy	2s
tblib	2s
cycler	2s
Jinja2	1s
Pygments	1s
pytest	1s
ply	1s
six	1s
micropip	1s
exceptiongroup	1s
py	1s
pkgconfig	1s

Longest build: libngspice (21m 58s)
Packages built in more than 10 minutes: 4

[agriyakhetarpal]

Thanks for fixing it! I am okay with this update, though let's hope that the next update can have a platform-specific inspice wheel directly pushed to PyPI, removing the recipe here... considering that it is fine to have both a pure Python wheel and a WASM wheel, since pip will pick the more specific WASM one during resolution.