Rename repo to pytorch-feedstock

[danpetry]

Would this be feasible? Existing git clone URLs will redirect to the new one automatically.

It would make more sense for obvious reasons.

[jakirkham]

In theory this would just be renaming the repo. However as some unknown person once said, "in theory, there is no difference between practice and theory. In practice, there is."

The reason this is complicated is there is a lot of background configuration adding webhooks, setting up teams, adding the feedstocks repo, configuring package outputs, etc.

At present there is only one place where we do this, which is when creating a new feedstock from a recipe in staged-recipes. So in a few cases we have readded recipes to staged-recipes under new names and archived the old feedstock with a reference to the new one

While I agree with you that would be nice to update the name here, going through our current process takes a bit of work. So am unclear whether it is worth it. Honestly it could be. Though would like to here from others here

Perhaps improving our process would help: conda-forge/admin-requests#1326

[hmaarrfk]

The reason this is complicated is there is a lot of background configuration adding webhooks, setting up teams, adding the feedstocks repo, configuring package outputs, etc.

Due to this, i see the risk as being very high, for "little" value.

I use this website to find packages that sound like the on I want and click on the few feedstocks that sound relevant.
https://conda-forge.org/packages/

[jakirkham]

That comment was on GitHub's repo renaming process not working for us

---

To rename a feedstock, we currently recommend adding the recipe with a new name to staged-recipes, which works well

Here's a simple example: conda-forge/hipscat-feedstock#22

Though our current renaming process does feel a bit extra

---

My guess is Daniel (like I) has to often explain to folks that the packages here are not CPU only. Particularly to folks less familiar with conda-forge and how it works. We can of course point folks to the package listing and the like. It would just be nice not to have these conversations regularly

That said, am unsure whether that outweighs the (temporary) disruption that would occur by renaming

[isuruf]

My guess is Daniel (like I) has to often explain to folks that the packages here are not CPU only.

Folks that use our conda packages don't need to know about this feedstock. Those that do need to know can read the README and we can explain in the README if it is insufficient.

[danpetry]

Thanks for the background. Well, we have a pytorch-feedstock repo, but it's not a fork, making it slightly more difficult to sync. We can workaround by adding a local remote config so it's not that big of a deal. (Would prefer not to rename to avoid internal confusion.)

Seems like the best approach then would be to add repo renaming functionality to the infrastructure if it gives enough benefit in the wider sense.

[hmaarrfk]

i must appologize for the naming. 4 years later i should have definitely kept things simple with pytorch-feedstock.

But at the time we didn't have the CI power to build out the GPU packages....

[h-vetinari]

Seems like the best approach then would be to add repo renaming functionality to the infrastructure if it gives enough benefit in the wider sense.

It's a pretty rare case, and usually the feedstock name doesn't matter. In a small number of cases we created an entirely new feedstock through staged-recipes and then force-pushed the old history. But it messes up all the issue & PR references in the git history.

So I don't think that general rename functionality will happen realistically - it's a huge amount of effort (given the number of edge cases involved), for a pretty rare occurrence.

We can workaround by adding a local remote config so it's not that big of a deal. (Would prefer not to rename to avoid internal confusion.)

I mean, if you just do

git remote add conda-forge https://github.com/conda-forge/pytorch-cpu-feedstock
git fetch conda-forge
git merge conda-forge/main --allow-unrelated-histories

then you'll never see the "pytorch-cpu" anymore, except when inspecting git remote -v.

[danpetry]

yep. sounds fine.