Repository navigation
fix: deprecatge PyPI package #190
Description
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?
Activity
john-halloran commentedon Mar 9, 2026
@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 commentedon Mar 9, 2026
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-nmffirst and worry about cleaning upsnmflater. Since snmf wasn't even fully working at that point, I think such an approach is pretty low risk.sbillinge commentedon Mar 10, 2026
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.0releasejohn-halloran commentedon Apr 1, 2026
@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 commentedon Apr 3, 2026
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?