Optional dependencies broken on Python 3.13/3.14: `munch` unusable, and `pandas` capped below 3

[prbprbprb]

Background

I'm using trading-ig in a personal project so I'm invested (ha ha) in helping keep it up to date without
breaking any existing users.

Updating CI and munch seems like a no-brainer, as is fixing trading-ig up for pandas 3.x, but actually
changing the dependency might be a breaking change for existing users. I have small PRs for the following
but thought I'd discuss here first to make sure I'm on the same page as the maintainers.

Summary

The munch and pandas optional-dependency pins in pyproject.toml have quietly fallen behind the
Python versions the package advertises. On Python 3.13+ munch cannot be imported at all, so
return_munch silently turns itself off and every munch-dependent path (and integration test) is skipped.
Separately, the pandas>=2,<3 cap blocks pandas 3, and conv_resol() still emits frequency aliases that
pandas 3 has removed.

The classifiers advertise 3.13 and 3.14, but CI only exercises 3.10–3.12, so none of this is caught.

Environment

• Python 3.14.6, trading-ig 0.0.24, trading-ig[munch,pandas] installed
• munch resolves to 2.5.0 (newest allowed by munch>=2.5,<3)

---

Problem 1 — munch 2.5 is un-importable on Python 3.13+

munch 2.5 does import pkg_resources, which is no longer available on Python 3.13+ which
the library's probe in trading_ig/utils.py treats this as "munch not installed".

Consequences:

• _HAS_MUNCH is False even though munch is installed, so IGService(return_munch=...) defaults
  off and JSON responses come back as plain dicts.
• The warning ("munch is not present in the environment") is misleading — the package is present, it just
  can't import.
• Every @pytest.mark.skipif(not munch_installed) integration test silently skips.

Proposed fix (non-breaking): raise the pin to munch>=4,<5

impact: none functionally. The only theoretical risk is a downstream that pins munch<4 for its
own reasons — rare, and such a consumer is already broken on 3.13+ today.

---

Problem 2 — conv_resol() uses frequency aliases that pandas 3 removed

trading_ig/utils.py::conv_resol() passes the caller's resolution string to
pandas.tseries.frequencies.to_offset. pandas deprecated the H and M aliases in 2.2 and removed them
in 3.0, so on pandas 3:

resolution passed in	pandas 2.3	pandas 3.0
1H, 2H, 3H, 4H	works (FutureWarning)	ValueError
M	works (FutureWarning)	ValueError
1h–4h, ME, 1Min–30Min, 1s, D, W	works	works

The docstring for fetch_historical_prices_by_epic() advertises the broken forms.

conv_resol also doesn't wrap the to_offset call, so an unrecognised alias raises out of the
function rather than falling through to its "return the input unchanged" branch, and this has no test coverage.

Proposed fix (non-breaking):

1. Normalise deprecated aliases before to_offset (H→h, M→ME).
2. Wrap the to_offset(resolution) call in try/except so an unknown alias falls through to the existing
   return resolution path instead of raising.
3. Update the fetch_historical_prices_by_epic() docstring to the current aliases (or document that both
   are accepted).
4. Add conv_resol tests to tests/test_utils.py.

Consumer impact: strictly widening. 1H/M start working on pandas 3 where they currently raise, and
stop warning on pandas 2. No change for callers already using lowercase aliases.

---

Problem 3 — CI doesn't test the advertised Python versions

classifiers list Python 3.13 and 3.14, but .github/workflows/unit-test.yml runs the matrix
["3.10", "3.11", "3.12"].

Proposed fix: add "3.13" and "3.14" to the unit-test matrix. (This is also what makes Problem 1's
fix verifiable in CI.)

---

Separate future discussion — the pandas>=2,<3 cap

Raising the cap is not proposed here — it deserves its own thread — but documenting it so the picture is
complete:

• The cap blocks trading-ig[pandas] from installing alongside a pandas-3 project.
• It appears to be an artifact rather than a decision: it entered as a poetry caret (pandas = {version = "^2"}, and the later uv migration expanded ^2 into the literal >=2,<3.
• The library itself looks close to pandas-3-clean: a from-scratch run of the unit suite on pandas 3.0.3
  passed (51/51), and the DataFrame mutation sites (expand_columns, format_prices) are direct
  assignment, not chained assignment, so Copy-on-Write (new in pandas 3) doesn't bite.
• But raising the cap is genuinely consumer-affecting: it lets a downstream pip install trading-ig[pandas] resolve to pandas 3, which changes Copy-on-Write and string-dtype behaviour in the
  consumer's own code, not just inside trading-ig. So it needs maintainer buy-in and probably a minor
  version bump.

Happy to open a separate issue for the cap if there's appetite.

---

[bug-or-feature]

@prbprbprb thanks for flagging this. Please go ahead and submit your PRs for 1, 2 and 3

[prbprbprb]

Thanks for the quick response! I'm flat out today but will get those to you ASAP.