duplicate feedstock

[beckermr]

This feedstock is a duplicate of https://github.com/conda-forge/python-build-feedstock. I was told by @isuruf that we did not want build as the name because it was too generic. I am going to archive this feedstock.

[beckermr]

cc @conda-forge/build

[beckermr]

cc @conda-forge/core

[beckermr]

We're going to wait one week and then archive this one.

[beckermr]

I got a thumbs up from a maintainer on the staged-recipes PR: conda-forge/staged-recipes#14233

Going to go ahead and archive now.

[beckermr]

Moving this note over from staged recipes:

@conda-forge/build if we mark all of the build packages a broken, will that break too much of your stuff using the build conda package?

FYI, once a package is marked broken it will no longer be installable in new environments and so CI jobs and other envs that depend on being able to install build will fail.

cc @isuruf

xref: conda-forge/staged-recipes#14233

[chrisburr]

I think there are sufficiently few downloads that the permanent harm of conda install build giving an unmaintained version is worse that temporarily breaking one or two workflows (if there even are any).

[beckermr]

Let's give the maintainers a little time to respond.

[jasongrout]

I'm fine with removing this in favor of python-build. The other two maintainers are build maintainers, so I'd love to hear from one of them too.

Would we automatically submit prs to any package that depends on this package to move it over to the python-build package?

[jasongrout]

Can the three of us be added as maintainers of the other package as well?

[FFY00]

I have a preference towards this feedstock as I would expect the package to have the same name in conda and pip, but it's not really my call.

I think there are sufficiently few downloads that the permanent harm of conda install build giving an unmaintained version is worse that temporarily breaking one or two workflows (if there even are any).

Isn't there a way to deal with these situations? It's not the first time I run into such issues with conda.

I also struggle a bit to understand the point of the name being too generic if this feedstock will still be reachable. It's not like the users will see an error, the only thing it helps is people being slightly less confused in documented commands.

[isuruf]

Would we automatically submit prs to any package that depends on this package to move it over to the python-build package?

Yes, we can make automatic PRs.

Can the three of us be added as maintainers of the other package as well?

Yes, of course.

I also struggle a bit to understand the point of the name being too generic if this feedstock will still be reachable. It's not like the users will see an error, the only thing it helps is people being slightly less confused in documented commands.

One proposal was to not maintain this feedstock, but keep the existing packages as they are. This would make conda install build succeed, but give an old version. We wanted to know if there would be an objection to remove build packages so that conda install build will error and only conda install python-build will work.

[jakirkham]

Just checking in here, what conclusion did we reach on next steps?

[jasongrout]

Good question, I've also wondered what the decision was. At this point, comparing downloads, we have 4589 downloads of python-build v0.7.0 and 11668 downloads of build v0.7.0, so I think the reasoning about breaking things and removing packages is very different now than from when the discussion happened.

[beckermr]

Yeah. The ship has sailed here. Let's add the build output to the python-build feedstock and move on. We can have smithy warn on depending on it and have the bot fix it.