FAQ¶

Do I need .NET installed?¶

No. The wheel contains a complete .NET runtime — about half of its ~60 MB, and the entire point: you should never have to know pyMzLib is C# underneath.

Do I need a specific Python version?¶

Python 3.9 or newer, and nothing more specific than that. pyMzLib has no compiled Python code, so one wheel works on every Python version — unlike most scientific packages, which need a separate wheel per version. See D7.

Will it conflict with my other packages?¶

It cannot. pyMzLib declares zero third-party runtime dependencies, so there is nothing for pip to resolve and nothing to disagree with anything else you have installed. This was a design requirement, not a happy accident.

Does it work with conda?¶

Yes — pip install mzlib inside a conda environment works, and because pyMzLib has no dependencies, it can't disturb conda's own resolution. A native bioconda package is planned.

Why is the wheel so large?¶

It contains a .NET runtime plus mzLib and its dependencies. The wheel is about 60 MB. For context: mzLib's own NuGet package is 31 MB, but a C# developer separately downloads TorchSharp and about a gigabyte of libtorch components — so this single file is far smaller than what using mzLib from C# costs. On PyPI it's ordinary: pyOpenMS is 63 MB, torch is 502 MB.

It used to be up to 166 MB. Nearly all of that was libtorch, a machine-learning library mzLib pulls in for one retention-time predictor that pyMzLib doesn't expose, so it's no longer shipped — the details.

Is it fast?¶

Each call costs about 120 ms of process startup (roughly a second on the first call of a session), so pyMzLib is built for coarse-grained operations — fetch a manifest, download files, run an analysis — not for calling inside a tight loop. The computation itself runs at C# speed once started.

If you need fine-grained numeric work from Python, please open an issue. That's a real gap and it needs a different transport underneath, which the architecture deliberately leaves room for.

Can I use mzLib feature X?¶

Only the areas on the home page are exposed so far, deliberately — coverage grows by demand rather than by guessing. Opening an issue is the fastest way to change that; the extension recipe is short.

Is there an R / Rust / Julia version?¶

Not today, but the executable pyMzLib drives has a language-neutral contract and would work unchanged from another language. Rust is the most likely next binding. If you'd use one, say so on the issue tracker — that's the evidence that decides it.

How does this relate to pyOpenMS / pyteomics?¶

Complementary, not competing. They wrap different libraries: pyOpenMS wraps OpenMS (C++), pyteomics is pure Python. pyMzLib brings mzLib's particular strengths — the machinery behind MetaMorpheus, especially top-down and proteoform work — to the same environment. Use whichever has what you need; nothing stops you using all three, since pyMzLib can't conflict with them.

Troubleshooting¶

`BridgeNotFoundError: No mzLib bridge for this platform`¶

The installed package has no payload for your platform. Almost always one of:

You installed from an sdist instead of a wheel. An sdist can't carry a platform binary. Check pip install --only-binary=:all: mzlib.
You're running from a source checkout where the bridge hasn't been built. See building from source.
Your platform isn't among the published wheels (linux-x64, win-x64, osx-x64, osx-arm64). Open an issue — adding one is a line of CI configuration.

`ServiceUnavailableError: … status 503`¶

PRIDE was unavailable. Not a pyMzLib problem; retry later.

This arrives as ServiceUnavailableError, not a plain BridgeError — the bridge classifies 408, 429 and 5xx as availability failures so you can retry them and report everything else. Since ServiceUnavailableError subclasses BridgeError, except BridgeError still catches it; catch the narrower one when you want to retry. See the PRIDE guide.

`ServiceUnavailableError: Received an unexpected EOF or 0 bytes from the transport stream`¶

The connection dropped part-way through a download. The server accepted the request and started sending, then went away — so it is an outage like any other, and retrying is the right response.

Large downloads are the usual place to meet it, simply because they are exposed for longer. If it repeats at roughly the same point every time, suspect something between you and EBI (a proxy or scanner cutting long transfers) rather than EBI itself.

Before pyMzLib 0.1.0.dev4 this surfaced as BridgeError

Older versions reported it under the raw .NET type name, which made an outage look like a contract break — retry loops written around ServiceUnavailableError did not catch it. If you wrote a workaround that also catches BridgeError for this message, you can drop it.

`BridgeError: NotSupportedException … no HTTPS-reachable location`¶

The file is published only over Aspera. Filter it out before downloading:

downloadable = [f for f in files if f.downloadable]

`PyMzLibError: bridge speaks protocol N, but this pyMzLib expects M`¶

The Python package and the executable came from different builds. Reinstall the wheel; if you're working from source, re-run publish-bridge.ps1 and check PYMZLIB_BRIDGE isn't pointing at a stale executable.

It hangs¶

download() has no timeout by default, because real transfers can take hours. Pass one if you'd rather it gave up: pymzlib.pride.download(..., timeout=3600).