release 4.2.3

[minrk]

appears to be needed for setuptools entrypoints to work.

cf conda/conda-build#1171

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

It is true that much newer versions of conda and conda-build will be needed to deal with these subtle entrypoint issues. However, they are not proper releases and are instead pre-releases unfortunately. Sadly we haven't settled on how to do that yet. Please see issue ( conda-forge/conda-forge.github.io#147 ).

We have been extraordinarily reluctant to use pre-releases of conda and conda-build in the past as seen in the discussion of PR ( conda-forge/conda-smithy#156 ). Maybe this time will be different due to the particular nature of the issues faced here. Though we really don't have a mechanism for controlling the release on a per feedstock basis. There is also a fair question of whether that should even be done at all.

At least from my perspective, these newer releases of conda and conda-build will require a fair bit of planning and work at conda-forge. Please see issue ( conda-forge/conda-forge.github.io#171 ). The short story is we are looking at a pretty large rebuild of the stack when these releases roll out. While some great work has been done to try to collect info on recent affected packages ( https://github.com/Anaconda-Platform/support/issues/44 ), there still seems to be some unanswered questions about what that will entail for older packages ( https://github.com/Anaconda-Platform/support/issues/57 ).

Based on discussion from our last meeting, it sounds like seeing formal releases of these is a few weeks off. Though, as mentioned, they are going to entail a lot of work. Personally I'm not ready for this work until I have some more information and a large enough block of time to dedicate to it.

In any event, if there is another path forward for you that works like conda's entrypoints, I would recommend following that path instead. Sorry if this is disappoint ATM, I'm just not sure we can go forward with this yet.

If there is info that I'm missing or have misunderstood myself, please feel free to correct me, @msarahan.

[msarahan]

It's only a large rebuild if we support long prefixes for absolutely everything. We have to rebuild the core at a minimum - things like libpng, zlib, etc. Just about everything else can be on-demand, and that time period can go on for a while. I don't think it needs to be done all in one go.

Also, keep conda and conda-build separate here. There are reasons for being cautious about both of them, but they are different reasons, with very different sources of potential breakage. Please do not evaluate one on the basis of the other.

Honestly, rebuilding the stack is probably less work than coming up with the proposal for how to do prereleases on conda-forge.

[jakirkham]

Also, keep conda and conda-build separate here. There are reasons for being cautious about both of them, but they are different reasons, with very different sources of potential breakage. Please do not evaluate one on the basis of the other.

It was my understanding that we would need to update this at the same time we switch to conda-build version 2.0.0 based on our last meeting. If that is not the case, could you please explain the upgrade path and why it might be ok to have one without the other?

[msarahan]

Conda build 1.21.11 includes fixes so that binary prefixes are detected with case insensitivity on Windows. Packages built by earlier versions will not have the prefix detected on Windows, so conda won't be able to replace prefixes when these packages are installed.

Conda build will not support long prefixes until 2.0, but that is irrelevant here.

Conda will not support binary prefixes on Windows until 4.2.3.