AB version and library version compatibility check on start of AB

[nabilahmed739]

Rationale: As in some cases, the same environment is used for multiple purposes, especially by the users of Brightway who also use AB, there could be incompatibility between the BW packages and possibly even for other libraries.

Compatibility check on start of AB:

• Single source of truth of compatibility lists OR dependency configuration and their versions including >= and <
• On start of AB, AB will self-check if the installed packages in environment are inline with AB's dependency requirements
• Based on the check, let user know which installed packages are incompatible and let user know the expected versions
• Also, check the channels and order?
• This check can be turned on/off

Documentation: Compatibility table for each version of AB in the README.md file

[haasad]

I agree that this would be a nice feature to have, but I think this will be almost impossible to get right, if at all possible. On the user side it should be easy enough to get the current state by calling conda list from within the AB. But what is the desired state to compare against? I see two options for this:

• a) we package a list of dependency requirements at build time
• b) the AB somehow gets and up-to-date list of requirements from the internet when doing this compatibility check

a) is a static list of requirements which will fast become outdated, so the user would frequently have to run conda update activity-browser, otherwise the compatibility check will be useless/wrong b) basically means rebuilding the conda dependency resolver, ie. doing the same as conda update activity-browser (minus the updating itself)

In my opinion, our best bet is to try an make sure that conda update activity-browser always produces a working dependency configuration and document it more clearly for users what to do if something doesn't work.

[haasad]

Regarding your statement from the other issue:

Additionally, lately we have been spending a lot of time manually diagnosing user's environment / package compatibility issues as many users use the same environment for multiple applications(using bw but maybe bw2.5, etc.).

The README states the following:

It is recommended that you have a separate conda environment for the activity browser like explained above, but you can also install the activity browser in your root, brightway2 or other existing conda environment if you prefer. Having separate environments for different projects generally reduces unwanted side-effects and incompatibilities between packages. You can still access the same brightway-projects even if you work with different conda environments.

In my opinion, users that don't follow this advice should know what they're doing, but maybe we need to make this more explicit.

One easy way to reduce the effort and time spent on helping users fixing their environment could be using github issue templates. Eg. having checkboxes that say something like:

• have you tried updating your environment? -> instructions
• have you tried installing the development version in a fresh environment? -> instructions

I'll try to make a PR when I find the time.