Arch Linux User Repository

OK, thanks to henriii, we got it!

pkgname=micromamba
pkgver=2.0.0
_srcver=2024.09.25 
_name=mamba-$_srcver
pkgrel=1
pkgdesc="The fast cross-platform package manager"
arch=('x86_64')
url="https://github.com/mamba-org/mamba"
license=('BSD-3-Clause')
depends=(
  'fmt'
  'libsolv'
  'python>=3.9'
  'reproc'
  'yaml-cpp>=0.8.0'
  'simdjson'
)
makedepends=(
  # header-only libs
  'cli11'
  'spdlog'
  'tl-expected'
  'nlohmann-json'
  # C++ build tools
  'ccache'
  'python-cmake>=3.18'
  'doctest'
  'python-ninja'
  'pybind11'
  # python build tools
  'python-build'
  'python-installer'
  'python-scikit-build>=0.13'
  'python-setuptools>=42'
  'python-wheel'
)
provides=("libmamba=$pkgver" "python-libmambapy=$pkgver")
replaces=('python-libmamba')
conflicts=('python-libmamba')
#options=(!emptydirs)
#backup=(etc/conda/condarc)
source=("$_name-$pkgver.tar.gz::$url/archive/refs/tags/$_srcver.tar.gz")
sha512sums=('6b3e64255f8aa63723dd08f578f79195b46249a02002b6d0d77713fd181f0557e3b6044075a823e639b0240b07b4e17dd0c9c17790c9152a68992e3ca9a599fa')

build() {
  cd "$srcdir/$_name"

  cmake -S. -Bbuild \
    -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON \
    -DBUILD_LIBMAMBA=ON \
    -DBUILD_LIBMAMBAPY=ON \
    -DBUILD_MICROMAMBA=ON \
    -DBUILD_MAMBA_PACKAGE=ON \
    -DBUILD_SHARED=ON
  cmake --build build --parallel 8
  cmake --install build --prefix install

  cd libmambapy
  export SKBUILD_CONFIGURE_OPTIONS="\
      -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON \
      -DBUILD_LIBMAMBA=ON \
      -DBUILD_LIBMAMBAPY=ON \
      -DBUILD_MICROMAMBA=ON \
      -DBUILD_MAMBA_PACKAGE=ON \
      -Dlibmamba_ROOT=$PWD/../install"
  python -m build -x --wheel --no-isolation
}

package() {
  cd "$srcdir/$_name"
  cmake --install build/ --prefix "$pkgdir/usr"

  cd "$srcdir/$_name/libmambapy"
  python -m installer --destdir="$pkgdir" dist/*.whl

  install -Dm 644 LICENSE $pkgdir/usr/share/licenses/${pkgname}/LICENSE.txt
}

OK, it also has some more build dependencies: python-cmake and python-ninja

python-ninja exists, and I packaged https://aur.archlinux.org/packages/python-cmake-bin for that reason. We might want to change it so it uses system cmake!

Once you updated this package to build and to have provides=(... python-libmamba) I can retire https://aur.archlinux.org/packages/python-libmamba

I think I’m almost at a point where I’m getting this to build. Only problem is that 2.0 calls cmake on its own, and I’m unsure how to deal with it. I asked the scikit-build people for help, let’s see.

I think the 2.0.0 release build just needs the added simdjson dependency and --preset mamba-unix-shared-release.

Could you also please add python-libmamba to the provides array? “libmambapy” is a python library with that name!

conflict and provides are useless and need to be removed. conflict itself should be conflicts
MIT license is wrong, the project uses BSD-3 clause license.
According to namcap several dependencies are not needed.

These seem to be only needed in make process, so move to makedeps

micromamba W: Dependency included, but may not be needed ('cmake')
micromamba W: Dependency included, but may not be needed ('cli11')
micromamba W: Dependency included, but may not be needed ('pybind11')
micromamba W: Dependency included, but may not be needed ('spdlog')
micromamba W: Dependency included, but may not be needed ('nlohmann-json')
micromamba W: Dependency included, but may not be needed ('tl-expected')

This is false positive as it needs pip to install packages, I guess to satisfy namcap one could move this to optdepends, but idk what else you can use mamba for other than installing packages.

micromamba W: Dependency included, but may not be needed ('python-pip')

These 2 can be dropped.
Since micromamba(or rather libmamba 0.26.0) it uses std::filesystem instead of ghc::filesystem.
Since 1.1.0 termcolor is no longer needed.

micromamba W: Dependency included, but may not be needed ('ghc-filesystem')
micromamba W: Dependency included, but may not be needed ('termcolor')

It is fixed here

I have the following error for upgrading to 1.4.4-1.

/home/parham/.cache/yay/micromamba/src/mamba-2023.05.16/libmamba/src/solv-cpp/solvable.cpp:153:81: error: ‘uint64_t’ is not a member of ‘std’; did you mean ‘wint_t’?
  153 |             std::numeric_limits<decltype(n)>::max() <= std::numeric_limits<std::uint64_t>::max()
      |                                                                                 ^~~~~~~~
      |                                                                                 wint_t
/home/parham/.cache/yay/micromamba/src/mamba-2023.05.16/libmamba/src/solv-cpp/solvable.cpp:153:89: error: template argument 1 is invalid
  153 |             std::numeric_limits<decltype(n)>::max() <= std::numeric_limits<std::uint64_t>::max()

It might be obvious to some folks, but if you get an error during compilation stating that core.h from FMT wasn't found, it is related to this report: https://bugs.archlinux.org/task/74295

So you need to rebuild and install spdlog first, with uncommented line "#define SPDLOG_FMT_EXTERNAL" in tweakme.h in the sources.

@izahn, I will update next libsolv release (see mamba issue #1155).

mamba has improved considerably over the last few months, it would be great to update this package to the latest version.