Ok this should be ready to go @conda/constructor. I have two main questions:

• Should we depend on apipkg or vendor it?
• apipkg has a few caveats, the main one is that once invoked, the namespace in that module is completely CLEARED. The fix is to reinject them via the attr kwarg. It works ok after that, but it was surprising behaviour. I added a comment to clarify, but I want to know if everyone is comfortable with that.

Thanks to the forwarders, menuinst v2 is backwards compatible with all the public calls I could find on Github (mostly conda.core.initialize).

I don't know how the team feels about adding one more dependency to the conda tree. If that's a problem we could vendor the apipkg project.

I know that apipkg has been around for a LONG time, so it's probably pretty well tested and used, but I also remember that Holger suggested to always vendor it as it's relatively small.

I also remember that Holger suggested to always vendor it as it's relatively small.

The README suggests is a single module, but all I see is a package with several (small) modules. Am I missing something? 🤔

Ah, that's v3. Maybe I try v2, which is indeed single-module.

pytest-dev/apipkg@2acee50 seems to have changed that, I didn't know that before

@jaimergp Hmm, seeing that the v3 also added Python 3.11 support (or at least testing), I wonder if dependening might actually be better :-/ It exists both on defaults and conda-forge: https://anaconda.org/anaconda/apipkg https://anaconda.org/conda-forge/apipkg but the versions don't match.

defaults is reaaally behind with 1.5.

We can vendor the whole v3 package too. Even if they are a few files. 🤷

WDYT about this way @jezdez?

@jaimergp that's alright, I think it might be a little easier to maintain when using pip's vendoring lib, but that can be done separately

(need to review the API here in depth, next week though)

Solving the conflicts dismissed the review, sorry @jezdez. Can you reapprove when you have a chance? Thanks 🙏