Add scikit-plots

[celik-muhammed]

Hi there,
I am one of the maintainers of scikit-plots doc and we would like to build nightly wheels and follow SPEC 4.

• main purposes for keep track fully latest changes immediately.
• increase compatibility mybinder.org and JupyterLite browser work environment into one source.
• currently 77 files (660.9 MB) for one version negotiable if size limitation too large (it designed produced dev version packeges override always like stable logic)
• nightly repo: https://anaconda.org/channels/scikit-plots-wheels-staging-nightly/packages/scikit-plots/overview
• Mostly dependencies exist here like runtime: numpy, scipy, matplotlib, pandas, scikit-learn, particially submodule Cython

Thanks.

[tupui]

Hi, thanks for reaching out. Can you give us a bit more context about the package? From a quick search it does not seem to have a large reach.

Most importantly, the nightly wheels are mostly intended for packages which have a large dependency graph (are depended upon by a lot of packages in the ecosystem.) For now, I am -1 mainly for that reason.

Other thing to consider: how hard is the package to build? If people can just use nightlies for all the dependencies and then the install from git simply works, then it's a disqualifier to me.

[celik-muhammed]

Hi @tupui, thanks for the quick response and the honest feedback.

I want to address both concerns directly. You are right that scikit-plots is not widely depended upon by other packages. We are a downstream consumer, not an upstream provider.

---

1. Build complexity — this is not pip install from git

Scikit-plots uses meson-python as its build backend (same logic as SciPy) and requires a full compiled toolchain to build from source:

• Meson + Ninja + Cython + pybind11 + Pythran
• NumPy C-API headers at compile time
• scikitplot.cython — a lightweight runtime Cython development kit with caching, pinning, garbage collection, and templating support; enables real-time, in-place generation of low-level Cython packages and modules for immediate use and testing
• Some C++ submodules:
  - scikitplot.annoy — approximate nearest-neighbor search over embedding vectors
  - scikitplot.nc — ships NumCpp C++ headers (scikitplot.nc.get_include())

pip install from git will simply fail without the full toolchain and initialized submodules.

---

2. JupyterLite / Pyodide — pre-built wheels are mandatory

One of our primary use cases is browser-based environments (mybinder.org and JupyterLite). Pyodide cannot compile C, C++, or Cython extensions at runtime — there is no workaround. Pre-built wheels are the only path to compatibility there.

---

3. Why the shared channel and not just our own

We already maintain scikit-plots-wheels-staging-nightly. The reason we are requesting the shared channel is not about hosting — it is about consistency. Right now our CI has to specify two separate --index-url entries: one for scikit-plots nightlies and one for dependency nightlies (numpy, scipy, matplotlib, scikit-learn). Being in scientific-python-nightly-wheels lets everything come from a single source.

Thanks again for taking the time.

[tupui]

Thanks for the reply. I am confirming my assessment and I am keeping my -1.

The difficulty to build is a good argument. But then it does not fit the bill as the package is at the end of the "chain" and not yet widely used. The last point about consistency seems then to be only an issue on your side.