menuinst
is able to take $PREFIX/Menu/*.json
files and create menu items on different OS. It is
used by conda
and constructor
to that end, but it's also a separate library.
menuinst
is aconda
dependency on Windows, but not on Linux/MacOS.menuinst
needs to be present on thebase
env soconda
can callmenuinst.install(...)
upon package linking if a menu JSON is found.
- Once support for Linux/MacOS is merged,
menuinst
needs to be part of theconda
dependencies on all platforms. - Remove special cases for Windows:
Note that the function that handles menu creation on conda
has this name and signature:
def make_menu(prefix, file_path, remove=False):
...
constructor
ships a frozenconda
calledconda-standalone
. This frozen package contains some vendored dependencies, likemenuinst
itself.constructor
allows--conda-exe
to specify a different "standalone conda" if needed. Conda Forge uses this flag to bundlemicromamba
instead.conda-standalone
has an extra entry pointconda constructor
, which provides some commands to create and remove menus. This introduces a CLI API:--make-menus
and--rm-menus
.- This entry point is part of the recipe itself!
- It should be part of the
conda
CLI, not just the standalone build.
- The entry point will import
_nsis.py
(part ofconstructor
) and callmenuinst.install(...)
. Note that_nsis.py
is only valid for Windows. _nsis.py
introduces a different API than conda!
def mk_menus(remove=False, prefix=None, pkg_names=None, root_prefix=None):
...
def rm_menus(prefix=None, root_prefix=None):
...
- Port
conda constructor
CLI API over toconda
. Havemicromamba
implement it too. - The CLI implementation should not call
_nsis.py
directly. It should usemenuinst
public API. This won't be a problem becausemenuinst
should be aconda
dependency at this point. _nsis.mk_menus
and_nsis.rm_menus
should be marked as deprecated and forward to the conda CLI implementation.