[MNT] maintenance & integration plan GC.OS

[fkiraly]

pyportfolioopt has joined GC.OS, this issue outlines integration into an umbrella maintenance model. This issue is to plan urgent maintenance items and handover.

Community input on todos and wishlist is also appreciated, e.g., what are "burning" items, suggested priorities.

Maintenance items

• [ ] pyproject review, dependabot PRs
• [x] python 3.11-3.14 compatibility
• [x] EOL for python 3.9
• [x] dependency review - is matplotlib needed?
• [x] move linting to ruff https://github.com/PyPortfolio/PyPortfolioOpt/issues/651
• [ ] stale PR review and triage - highest priority
• [ ] test that tutorial notebooks run, fix any breakage
• [ ] optional: conda releases

handover items

• [ ] issue triage
• [ ] bugfixing board - tagging bugs and moving to board
• [ ] stale PR review and triage - all
• [x] operational handover
• [ ] pointers to dev channels
• [x] digital assets
• [ ] release pipeline

roadmap items for consideration or wishlist

• [ ] test coverage review (not just line coverage but case coverage)
• [ ] sklearn-like API review

[fkiraly]

WDYT, @robertmartin8?

[robertmartin8]

Hi, I agree with your priorities:

1. Ensure the package is currently stable and installable
2. Move to current best practices for installation (though I would like to retain backwards compatibility with simple pip and requirements.txt). Happy to move to uv instead of poetry though.

Generally speaking, I am quite agnostic and uneducated on the devops side of python packages, so I defer to the expertise of you and @tschm who have much more experience here

[tschm]

I have no experience with conda and it's not needed these days. I have also observed over the years tons of issues with all those solvers cvxpy comes out of the box with. There's today cvxpy-base which is like cvxpy but has no solvers! Modern versions of cvxpy use clarabel as standard solver. I would therefore suggest to move to cvxpy-base and clarabel (as an explicit dependency). I am also not keen on Matplotlib. I would move to plotly. Shall we support 3.10? It has started to die...

[fkiraly]

Hi, I agree with your priorities:

1. Ensure the package is currently stable and installable

2. Move to current best practices for installation (though I would like to retain backwards compatibility with simple pip and requirements.txt). Happy to move to uv instead of poetry though.

agreed with pip compatibility, that is crucial.

requirements.txt I would have removed, but I will add it back - backwards compatibility with workflows is important (though it impacts only the developer workflow).

[fkiraly]

I have no experience with conda and it's not needed these days.

conda is losing ground, but I think it is still an important distribution channel. Also, in some professional communities it is still primary channel or substantial.

I do not have exact numbers though - for our packages at GC.OS, conda usually amounts for around 5-15% of downloads, though this is declining.

[tschm]

The bad performance of conda was the reason we moved to poetry in 2021 :-) We love a good lock file

[fkiraly]

@tschm, yes, but you need to distinguish two setups: (a) maintaining a package that many people are using, and (b) maintaining an end-to-end pipeline in deployment for your company.

With (a), you want the package to be as useable as possible and as compatible as possibly with different preferences of different people. That often means going for the "most compatible" solution, and maintaining multiple compatibilities, such as with windows, unix; or pypi and conda; or being compatible with pip, uv, etc.

For (b), one prefers a narrower set of compatibilities, to increase maintainability and stability for yourself. Going for less compatibility and more maintainability or performance makes much more sense here - since you do not need to be compatible with any downstream usually.

(b) is probably the setup where you operate in with great experience and/or success - but my point is, some "best practices" do not translate, and sometimes even contradict those in (a).