fix: deprecatge PyPI package

[sbillinge]

Problem

diffpy.snmf exists on pypi but this is no longer used.

Proposed solution

Deprecate it. It is not allowed to simply remove packages, so follow PyPi protocols for how to do this. Basically, have it point to a legitimate version of the package but at the same time provide a deprecation message, something like that.

I didn't check if it is also on conda-forge with the old name, but if it is we have to do the same work over there (though the process may be different)

We need to do the same deprecations for any documentation that exists under the old name.

@john-halloran please can you look into this?

[john-halloran]

@sbillinge Yes, will do. To confirm, the goal is that if someone tries to install snmf through PyPi or conda-forge they will get a message saying warning: no longer supported, try stretched-nmf if you want this functionality?. Or alternatively,warning: no longer supported, package is now called stretched-nmf? I'm guessing we can't just have it fully/silently redirect to the new name, because that would be easiest if it's allowed.

[john-halloran]

This is what I've found as good guidance online for a migration plan. Since I'm not the maintainer or owner of the projects on those platforms, I won't be able to do this personally. Luckily, it seems like we can release stretched-nmf first and worry about cleaning up snmf later. Since snmf wasn't even fully working at that point, I think such an approach is pretty low risk.

• PyPI (diffpy.snmf)
  1. Make sure diffpy.stretched-nmf is published and installable first.
  2. Publish one more diffpy.snmf release as a shim:
     • Requires-Dist: diffpy.stretched-nmf>=<min_version>
     • README/description starts with “diffpy.snmf is deprecated; use diffpy.stretched-nmf”.
  3. Keep the old project name owned for safety
  4. Optionally archive the old project after the dummy release
• conda-forge
  1. Ensure diffpy.stretched-nmf feedstock/package exists.
  2. In old diffpy.snmf feedstock, publish a noarch transition build that depends on diffpy.stretched-nmf.
  3. Coordinate rename cleanup with @conda-forge/core (old feedstock/package handling is a core/admin process).

[sbillinge]

yes, that is more or less what I found too. This seems like a concrete course of action. Thanks @john-halloran . Let's follow this after the 0.2.0 release

[john-halloran]

@sbillinge I am ready to move forward on this, but it seems like it will require publishing one more (deprecation-focused) release under the diffpy.snmf name. What's the best way to do that, given that this repo is now under the new name?
My instinct would be to make a clone of the GH repo (ideally, as it was for the release of 0.1.3) under the diffpy.snmf name, but you may know a better way.
Or, if preserving that history is not important, since it's still in the commit history here, the deprecation release could simply be "blank", but that would raise other questions about what scaffolding to include.

[sbillinge]

let's get help from Claude or chatgpt for the steps on this. I wll have to push out the release so we could do it on a call after you figure out the steps. Do we actually need a release from the repo, or simply building something with the right name and the right dependency and deprectation message. Perhaps we build a local directory with this name and it just has a pyproject.toml in it and whatever else is needed for it to build and this gets uploaded to pypi. Maybe create a repo on your namespace with this name and play around with it?