Dispute deprecation of conda-build entrypoint

[mbargull]

In gh-4921 the conda-build entry point (and others) has been marked for deprecation in favor of only be callable through conda.

I don't really understand the motivation behind this.
Many of the longstanding issues with conda, conda-build and related projects has been due to the lack of modularity and overly intertwined code (on many levels).

IMO, removing the conda-build script is a step in the wrong direction once again since it further intertwines the projects (here on the highest level, i.e., the user's entrypoint) instead of working to increase modularity (contrary to good recent changes like conda-libmamba-solver, conda-index).

We should reconsider what the best way forward is here long term.
As is, this deprecation arguably only offers little (well, IMO, even negative) benefit and causes unnecessary user interface breakage (e.g., speaking for myself, I never run conda build but only ever conda-build and make a clear distinction between the package manager and the build tool).

[kenodegard]

In #4921 the conda-build entry point (and others) has been marked for deprecation in favor of only be callable through conda.

I don't really understand the motivation behind this.

This is motivated by the need to update to the new plugin framework in conda. The previous method of defining conda-* executables for conda to recognize as subcommands is slated for deprecation (see here).

---

I also view this deprecation as an opportunity to remove ambiguity (possibly even correcting user behavior). For example, if the user installs conda-build into their base env and into another env, running conda build will always invoke conda-build as installed into the base env while running conda-build will depend on which env is activated. After deprecation users will need to be much more explicit if they want to use a non-base env conda and run $CONDA_PREFIX/bin/conda ....

I do understand the concern, I've been torn over this myself.

[mbargull]

This is motivated by the need to update to the new plugin framework in conda. The previous method of defining conda-* executables for conda to recognize as subcommands is slated for deprecation (see here).

Yes, I understand that this is the motivation for the internal change (integrating as subcommand plugin).
But this is not a good enough motivation for the external change (removing conda-build binary/script).
This conflates internal with external changes.

---

I also view this deprecation as an opportunity to remove ambiguity (possibly even correcting user behavior). For example, if the user installs conda-build into their base env and into another env, running conda build will always invoke conda-build as installed into the base env while running conda-build will depend on which env is activated. After deprecation users will need to be much more explicit if they want to use a non-base env conda and run $CONDA_PREFIX/bin/conda ....

I do understand the concern, I've been torn over this myself.

It's not that clear, unfortunately.
"running conda build will always..." is only true for interactive use (or when people explicitly sourced etc/profile.d/conda.sh or ran eval "$(conda shell.posix hook)").
It is not true for typical non-interactive use, e.g., conda activate build-env && ./run-the-build for which in ./run-the-build running conda build and conda-build will always (well, on non-Windows...) run build-env's conda-build.

The "original sin" was to not decouple conda-build completely when it became its own thing.
With conda>=4.4's shell function this became the issue (which conda-build is ran for conda build) we see here again.

(I would not even be opposed to sidestepping this overall by another entrypoint that doesn't have the conda- prefix 😄...)

[dholth]

It has caused bugs when we have to go through conda's initialization before we can go through conda-build's initialization. Maybe some kinds of conda-* are more tightly "part of conda" than others.

+1 on distancing conda-build from conda's CLI

[kenodegard]

As mentioned in #5151 we have opted to postpone deprecating the entrypoints pending this discussion.