docs: present pip + conda-forge install, drop stale environment.yml

[daharoni]

Should follow #305.

What

Modernizes the install docs now that pymetis is gone and every dependency ships wheels, so a plain pip install works on all platforms (Windows included).

• install.rst - present pip and conda-forge side by side instead of conda as "the recommended way." Note that pip installs need FFmpeg separately while conda-forge bundles it. Switch the from-source step from conda env create -f environment.yml to pip install -e . (with pdm install noted for maintainers).
• README.md - Quick Start now offers pip or conda-forge for the install step.
• environment.yml - removed. It was a hand-maintained conda env pinned to python=3.8 / 2021-era deps; dependencies now live in pyproject.toml, and the only thing that referenced it was the from-source doc line.

conda-forge stays a first-class, documented install path (it's the easy one for FFmpeg) - this only drops the stale hand-curated env file and the "conda is the only recommended way" framing.

Why target feat/pypi-publish

These docs tell users to pip install minian, which only works once the PyPI publish is set up (the package name transfer). Basing this on the pypi branch makes the ordering explicit: merge this after PyPI publishing is live.

Out of scope

Left alone: the conda-forge packaging guide in contribute.rst (still valid), the conda badge, and tangential conda mentions (faq.rst nbextensions, a jemalloc comment in minian/__init__.py).

Follow-up: pointing conda-forge at PyPI

This PR documents conda install -c conda-forge minian as a first-class path, but conda-forge currently builds the old v1.x tags from GitHub. To make conda-forge track PyPI going forward (so "PyPI is source of truth, conda-forge is downstream"), the following needs to happen — after the first modernized PyPI release is live (see RELEASING.md). Note minian is already on conda-forge (conda-forge/minian-feedstock), so this is an update to the existing feedstock, not a new submission.

One-time feedstock PR (in conda-forge/minian-feedstock, a separate repo) against recipe/meta.yaml:

• Point source: at the PyPI sdist instead of a GitHub tag:

  {% set version = "2.0.0" %}
  source:
    url: https://pypi.io/packages/source/m/minian/minian-{{ version }}.tar.gz
    sha256: <sha256 of the sdist>

  (Building from the sdist freezes the version in PKG-INFO, so pdm-backend's SCM versioning needs no git history.)
• build: noarch: python — minian itself is pure Python (only deps have compiled parts).
• requirements: host: → python >=3.10, pip, pdm-backend (the build backend).
• requirements: run: → add the new deps pooch and ffmpeg (the binary — so conda users get FFmpeg automatically), bump python >=3.10.
• Entry points (minian-install, minian-notebooks, minian-data) are created automatically by pip install . from [project.scripts].
• test: → imports: minian plus a CLI smoke check (minian-data --help).
• Confirm the right people are under extra: recipe-maintainers:.

Ongoing (automatic): once the recipe sources from PyPI, regro-cf-autotick-bot auto-opens a version-bump PR (version + sha256) on the feedstock for every future PyPI release; a maintainer just reviews and merges.

Checklist:

• First modernized release published to PyPI (RELEASING.md flow)
• Feedstock PR: source: → PyPI sdist + sha256; noarch: python; host pdm-backend; run add pooch + ffmpeg; python >=3.10; verify entry points + test
• Confirm feedstock maintainership
• Merge → conda-forge builds → autotick bot tracks future releases

Out of scope here: contribute.rst's conda-forge section still describes the old manual local-build flow (conda-build/conda-smithy) rather than the feedstock-PR flow; worth refreshing separately.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sneakers-the-rat]

sounds good. sort of lost me at the end there, but i'll just read the code. I don't have much experience with feedstocks, so i'll leave that one up to you, i'm sure there's some reasonable way of having it autoupdate without needing to juggle a yaml file, someone set up something for numpydantic and the feedstock repository i guess has a few thousand examples

[daharoni]

Yep, that last part is just a note for me on how to have conda auto update based on pypi. https://github.com/conda-forge/minian-feedstock is what is used to update the conda minian package and if we change the meta.yml file there based on this PR then from that point on conda will be driven by pypi updates.