[Debichem-devel] mmass is back, as mmassx: ITP filed, looking for review/co-maintenance

[David Sandquist]

Hi all,

mmass (previously maintained by this team, #525675, removed from unstable
in 2019-10-18 after upstream went quiet) has an actively maintained
successor: mMassX, https://github.com/SCIENCE-OPEN/mmassx
a Python 3 port with current dependencies.

I've filed a fresh ITP (bug number to follow once it clears the BTS) and
started a packaging skeleton at
https://github.com/katalystnord/mmassx-debian, built on top of the mmassx
upstream repo.

It builds cleanly and passes lintian with no errors, and I've gone well
past just building it: I actually drove the app through its main window,
spectrum loading, About dialog, Preferences, and periodic table, not just
launched it once. That surfaced seven real upstream bugs: mspy/calculations
(a mandatory C extension) never built on Linux; a wxPython/numpy
compatibility crash on the very first canvas draw; two dialogs (the shared
progress dialog and the About box) crashing on open from the same wxWidgets
sizer/parent mismatch; every http://mmass.org/ link in the app being dead,
since that domain is now parked; the Preferences dialog's Software Updates
page rendering every widget on top of every other; and the periodic table
crowded to the point of unreadable from a leftover negative grid gap (looks
like a GTK2-era compensation that GTK3 no longer needs). I've
packaged fixes for all of them as patches and sent the same fixes upstream:
https://github.com/SCIENCE-OPEN/mmassx/pull/2 -- mmassx's maintainer has
already had a first look and the branch is stable for review now.

One packaging decision I went back and forth on and want your take on. I
initially pulled the old mmass 5.5.0-5 packaging from
https://snapshot.debian.org/ and mirrored its binary split: mmass
(Architecture: all) for the app, mmass-modules (Architecture: any) for just
the compiled calculations extension. But the mechanics behind that
split don't carry over cleanly:

- The old mmass was Python 2, and mspy's submodules used implicit relative
imports (e.g. mod_signal.py just did `import calculations`). In Python 2,
when an implicit relative import doesn't find the module in its own package
directory, it falls back to an ordinary absolute import across sys.path.
That's what let the old package physically separate the two halves: mmass
shipped the pure-Python mspy/*.py under /usr/share/mmass/mspy/,
mmass-modules shipped
calculations.so under a completely different
directory, /usr/lib/mmass/mspy/, and debian/start-script bridged them
by setting PYTHONPATH=/usr/lib/mmass/mspy/ before launching.

- mmassx is Python 3, and its code uses explicit relative imports (`from .
import calculations`), which never fall back to a sys.path/PYTHONPATH
search; they strictly resolve within the
package's own directory. So I had to bridge the two packages with a symlink
instead, plus a version-locked mmassx-modules dependency. It worked (built,
tested, launched fine through the symlink), but it's a lot of extra
machinery for what the split was buying: for a single 44KB compiled
extension against a ~3.5MB package, the arch:all/any split saves
essentially nothing in mirror footprint or build time, which is really the
only reason to do it. Current dh-python/pybuild practice for a Python 3
module with one compiled extension is just to ship it as a single
Architecture: any package (that's what python3-lxml, python3-numpy, etc.
do), not to split
out a "-modules" package the way python-support/pycentral packaging did
back in the Python 2 era.

So I've gone with a single monolithic mmassx (Architecture: any) package
instead of reproducing the old split. If there's a reason the team would
still want it split for this one, I'm glad to redo it, but that's my
current call.

If the team would like to co-maintain this under Debichem once it's in
shape, I'm happy to move it to Salsa; equally happy to just get review from
people who remember the quirks of the original package.

Thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debichem-devel/attachments/20260908/d2d9a67f/attachment-0001.htm>