Must conda-build be installed in the base envt?

[jbednar]

Conda's docs include explicit advice to install "programs" into an environment separate from base, where conda itself resides. Does conda-build count as a "program" in that sense, not to be installed in base?

In my own work I always install conda-build into base, reasoning that is a part of conda in some ways, plus I've been working with people who had problems (possibly now addressed by https://github.com/conda/conda/releases/tag/23.7.3) when they installed conda-build in their non-base environment. Yet I can't find any explicit statement about where to install conda-build. The conda-build docs simply say to conda install conda-build, which for most users will end up in their non-base environment if they follow the blanket conda recommendation not to install into base.

If conda-build should be installed into base, I think the docs should be updated to state that explicitly. If it can be installed either in base or another environment, it would be great to list any limitations there are on that -- what happens when conda in base and conda-build are very different versions? Must a compatible conda always be installed alongside conda-build in the non-base environment? Etc.

[DaveKaretnyk]

I'm one of the people @jbednar is assisting. Looks like things are working properly for us if we stick to the recommendation of conda package building in the base env (little more checking still to do, but looks good). I'll be writing up a 'conda-build way of working' for Thermo Fisher so we can continue.

If it might help others I'd be happy to edit that content and submit it as a change to the conda-build docs here. Is that of interest to you or should I just leave you to it?

[jaimergp]

I think the main complication was the inability to run conda build from a non-base environment (you'd need conda-build instead, note the dash), but maybe there are some surprising bugs here and there. Running from base is fine as long as the env doesn't get polluted with too many packages. conda-forge's infra runs it from base, for example.

[kenodegard]

Historically it was possible (and at one point perhaps even necessary when building certain types of packages) to install conda-build into non-base environments.

Even today (with the exception of the recent regression introduced in conda 23.7.0 and fixed in conda 23.7.3) users can run conda build (note no dash) and invoke the conda-build installed into a non-base environment. This is simply an (unintended?) feature of how old plugins were invoked by spawning a subprocess calling the conda-build executable found on the user's $PATH.

However, invoking a plugin installed into a non-base environment using the new plugin framework is not possible. The new plugin framework runs conda and any of its plugins within the same process. While we loose the ability to install plugins into non-base environments we gain the ability to create much more powerful plugins that can tweak and modify the conda functionality itself.

So moving forward, yes, the recommendation is for conda and any of its plugins to be installed into the base environment.

[jbednar]

Thanks! I think that addresses my issue, as soon as that recommendation makes its way into the docs. @DaveKaretnyk , still up to make the docs PR?

[DaveKaretnyk]

Sure, happy to have a go at a small docs update. I need to finish off Thermo Fisher work then I can have a look - over weekend probably, if that fits Anaconda's expectations?

[DaveKaretnyk]

I have some suggested doc changes ready.

Slight detour along the way... Setup on Windows was not really working so I ended up using an Ubuntu installation via WSL. Then I expected I could create a branch off main, then deliver it back to the repo and make pull request of it. But I get a permission denial erro - some quick googling - I need to do this work via a fork of main? I'll figure it out, but if anyone is on the air let me know please...

[kenodegard]

@DaveKaretnyk Correct, you need to create a fork: https://docs.github.com/en/get-started/quickstart/fork-a-repo

[DaveKaretnyk]

pull request for docs here: #5004. Hopefully I've done the required steps....

I'm still getting used to your workflow - it's bit different from how we are using github and gitlab in our company. Different but better :-)

[jbednar]

I find the internal-project github workflow (without using forks) is a lot more convenient, but it's not really scalable to an OSS project, because then every contributor would be making branches on the main repo, and the repo would get unwieldy.

[kenodegard]

Docs updated in #5004