Closed ruben-arts closed 1 year ago
Thanks @ruben-arts ! I just tried your instructions on a system in which mamba was already installed using mambaforge (mamba version 1.4.2) with default installation, and it seems that the proposed micromamba installation has some serious side effects on existing mambaforge installations. Once you install micromamba with the specified instructions, it seems that:
mamba create -n testenv
starts creating an environment in ~/micromamba/envs/testenv
, while before it created it in ~/mambaforge/envs/testenv
. From the command output, it seems that somehow now mamba create
is no using micromamba
under the hood.
The main problem is that if I then run:
mamba activate testenv
the command fails with:
traversaro@IITICUBLAP257:~$ mamba activate testenv
EnvironmentNameNotFound: Could not find conda environment: testenv
You can list all discoverable environments with `conda info --envs`.
as if instead mamba activate
was looking for environments in ~/mambaforge/envs/
Not directly related to the PR, but to get a micromamba
working in a way compatible with an existing installation of conda/mamba via conda-forge in bash, I first removed the micromamba installed by https://micromamba.pfx.dev/install.sh
and then I did:
mamba activate base
mamba install micromamba
micromamba shell init --shell=bash --prefix=$CONDA_PREFIX
@traversaro Ouch that is not a nice change to your system. It simple runs micromamba shell init -p $PREFIXLOCATION
which then probably makes that location the default for all mamba tools. Except for the shell based command.
Although, that issue doesn't align with the goal of my PR. What do you think would be best here? Personally, I'm a huge fan of micromamba
but I could leave out the installation of it and just link to multiple ways of installing it.
@traversaro Ouch that is not a nice change to your system. It simple runs
micromamba shell init -p $PREFIXLOCATION
which then probably makes that location the default for all mamba tools. Except for the shell based command.
Why is that not nice? I have all my existing environments (that I would like to use with micromamba) at ~/mambaforge
, that once I run mamba activate base
is the directory to which $CONDA_PREFIX
points, so it seems the most natural thing to me to use micromamba
with my existing environments.
Although, that issue doesn't align with the goal of my PR. What do you think would be best here? Personally, I'm a huge fan of micromamba but I could leave out the installation of it and just link to multiple ways of installing it.
Probably @Tobias-Fischer may have a more strong opinion on this, but to be honest for simplify the PR I would separate the "cleanup/update of getting started" from "switching to micromamba" part of the PRs. micromamba seems indeed quite cool, but at the moment we are using mamba/mambaforge in several places in the documentation (see https://github.com/search?q=org%3ARoboStack+mamba+language%3AMarkdown&type=code&l=Markdown), so if we want to switch to recommending micromamba it would probably make sense to recommend it consistently in the docs.
Testing again the new documentation, it seems that in this new documentation the ros1_env
and ros2_env
environments do not have anymore robostack-staging
channel configured, as opposed to the old documentation. This may be confusing for users as a tipical workflow is to first create an environment just with (for example) ros-noetic-desktop
, and then install new packages with (for example):
mamba install ros-noetic-plotjuggler
after this modifications, this command would fail with:
(ros1_env) traversaro@IITICUBLAP257:~$ mamba install ros-noetic-plotjuggler
__
__ ______ ___ ____ _____ ___ / /_ ____ _
/ / / / __ `__ \/ __ `/ __ `__ \/ __ \/ __ `/
/ /_/ / / / / / / /_/ / / / / / / /_/ / /_/ /
/ .___/_/ /_/ /_/\__,_/_/ /_/ /_/_.___/\__,_/
/_/
conda-forge/linux-64 Using cache
conda-forge/noarch Using cache
Pinned packages:
- python 3.9.*
error libmamba Could not solve for environment specs
The following package could not be installed
└─ ros-noetic-plotjuggler does not exist (perhaps a typo or a missing channel).
critical libmamba Could not solve for environment specs
while I know that I just need to manually add -c conda-forge -c robostack-staging
to every install
or update
command, users that are not expert in conda/mamba/micromamba may be confused by this, this is why we added the conda config --env --add channels robostack-staging
commands back in time, there is any specific reason to remove them?
Why is that not nice?
I meant to say that its not nice that you encountered the side effects.
I think you gave some good feedback let me try to make it simpler and possibly split it in two PR's .
@traversaro I updated the looks and kept the mamba installation, what do you think of this setup? points of improvement would be great!
Hi @ruben-arts, thanks so much for taking this initiative! The different README's spread across the RoboStack repositories have been bothering me for a long time. We should take this as an opportunity to have a single installation instructions point, and refer to it from https://github.com/RoboStack/ros-noetic and https://github.com/RoboStack/ros-humble.
We should make sure that (almost) everything contained in these README's also shows up somewhere here, and then a simple link should do the job.
What do you think?
@Tobias-Fischer That is a very good point. Totally agree with combining it all on this website! It also feels like the contribution.md's could be grouped together in this repo aswell.
Yes agree that'd be amazing :)
@Tobias-Fischer I added some more info from the readme's to the docs pages and added a support page. I hope this fits well and is enough to get the PR in. If so we can update the readme's to link here.
I'll have a look at this soon, thanks again a lot @ruben-arts. Reminder to self: before merging, update references to x86_64
with uname -m
so it's platform agnostic.
Hi @ruben-arts - I finally got around looking at this - it's amazing, thanks so much! Looks really great and makes a big improvement over the current state.
While testing the robostack channel I wasn't able to use the documentation. And it had a lot of info that was just confusing.
I hope this simplifies it. And that it gets easier to use for starters.
Ran the commands on Windows and Fedora