micromamba: bump to 2.0.1

[henryiii]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

This is a replacement for #191869 and #192460. This doesn't add a mamba symlink to micromamba, since micromamba and mamba do not have the same interface.

[request-info]

Please provide a better issue/pull request title and/or description!

[daeho-ro]

  CMake Error at cmake/Checks.cmake:9 (message):
    Expected type "STATIC_LIBRARY" for target "yaml-cpp::yaml-cpp" but found
    "SHARED_LIBRARY"

I noticed that the yaml-cpp is build with the shared option.

homebrew-core/Formula/y/yaml-cpp.rb

Lines 23 to 26 in 5406dc1

	def install
	system "cmake", ".", *std_cmake_args, "-DYAML_BUILD_SHARED_LIBS=ON",
	"-DYAML_CPP_BUILD_TESTS=OFF"
	system "make", "install"

Digging more history about why it is build with shared option.

lembacon@6199d97

Maybe no reason :)

---

From the yaml-cpp documentation,

yaml-cpp builds a static library by default, you may want to build a shared library by specifying -DYAML_BUILD_SHARED_LIBS=ON. ...

so we may require to build and use the static one.

[carlocab]

We ship the shared libraries according to Homebrew policy: https://docs.brew.sh/Acceptable-Formulae#shared-vs-static-libraries

Formulae should link to shared libraries. There are some intransigent build systems that refuse to do so, but we should fix those wherever we can.

[carlocab]

Let's just ship mamba instead if that's the binary that supports shared linkage.

[henryiii]

Shouldn't the formula be named mamba then?

[carlocab]

Sure, we could do that. Though maybe we should just add a new mamba formula and deprecate this one.

I'd have suggested a formula rename, but you've said that micromamba and mamba do not expose the same interface.

[henryiii]

I'm only interested in the new interface, the old "conda-compatible" one doesn't really have any reason to exist, IMO, now that conda has a (default) libmamba solver. But the micromamba interface is cleaner and using it is better in CI. I'll see if I can get any devs to comment.

[henryiii]

Ah, I'm now wrong:

Mamba 2.0 Changes
Command Line Executables

Mamba (executable)

mamba, previously a Python executable mixing libmambapy, conda, and code to bridge both project is being replace by a fully C++ executable based on libmamba solely.

It now presents the same user interface and experience as micromamba.

https://mamba.readthedocs.io/en/latest/developer_zone/changes-2.0.html

Okay, that's a breaking change, and so I think renaming to mamba and just providing mamba is likely the correct path forward.

In my defense, the docs still claim it has a different interface in several places.

[henryiii]

Can I just rename the formula in the PR? Or is there more to do?

[carlocab]

If it's just the same now can't we just build mamba and create a symlink?

[henryiii]

Yes, but should the formula still be renamed? Or an alias added (since both are shipped in one formula, that seems best?)?

[carlocab]

Alias is probably simpler.