condacolab
condacolab copied to clipboard
conda-incubator
Weird conflict errors
I adapted the example notebook: https://colab.research.google.com/drive/1HjikV9AS7X4eklbPtauTG_N6XNGIwOHG?usp=sharing
But I get the following errors:
platform: linux-64
Collecting package metadata (repodata.json): ...working... done
Solving environment: ...working...
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed
Traceback (most recent call last):
File "/root/miniconda3/bin/constructor", line 11, in <module>
sys.exit(main())
File "/root/miniconda3/lib/python3.9/site-packages/constructor/main.py", line 244, in main
main_build(dir_path, output_dir=out_dir, platform=args.platform,
File "/root/miniconda3/lib/python3.9/site-packages/constructor/main.py", line 112, in main_build
fcp_main(info, verbose=verbose, dry_run=dry_run, conda_exe=conda_exe)
File "/root/miniconda3/lib/python3.9/site-packages/constructor/fcp.py", line 387, in main
_urls, dists, approx_tarballs_size, approx_pkgs_size, has_conda = _main(
File "/root/miniconda3/lib/python3.9/site-packages/constructor/fcp.py", line 295, in _main
precs = list(solver.solve_final_state())
File "/root/miniconda3/lib/python3.9/site-packages/conda/core/solve.py", line 281, in solve_final_state
ssc = self._run_sat(ssc)
File "/root/miniconda3/lib/python3.9/site-packages/conda/common/io.py", line 88, in decorated
return f(*args, **kwds)
File "/root/miniconda3/lib/python3.9/site-packages/conda/core/solve.py", line 815, in _run_sat
ssc.solution_precs = ssc.r.solve(tuple(final_environment_specs),
File "/root/miniconda3/lib/python3.9/site-packages/conda/common/io.py", line 88, in decorated
return f(*args, **kwds)
File "/root/miniconda3/lib/python3.9/site-packages/conda/resolve.py", line 1322, in solve
self.find_conflicts(specs, specs_to_add, history_specs)
File "/root/miniconda3/lib/python3.9/site-packages/conda/resolve.py", line 352, in find_conflicts
raise UnsatisfiableError(bad_deps, strict=strict_channel_priority)
conda.exceptions.UnsatisfiableError: The following specifications were found to be incompatible with each other:
Output in format: Requested package -> Available versions
Package _libgcc_mutex conflicts for:
python==3.8 -> libgcc-ng[version='>=7.3.0'] -> _libgcc_mutex[version='*|0.1',build='conda_forge|main']
cudatoolkit=11.0 -> libgcc-ng[version='>=7.3.0'] -> _libgcc_mutex[version='*|0.1',build='conda_forge|main']
Package cudatoolkit conflicts for:
cudatoolkit=11.0
rapids==21.12 -> cudatoolkit[version='11.0.*|11.2.*|11.5.*|11.4.*']
rapids==21.12 -> cucim=21.12 -> cudatoolkit[version='10.0|10.0.*|10.1|10.1.*|10.2|10.2.*|11.0|11.0.*|11.1|11.1.*|>=11,<12.0a0|>=11.2,<12|9.2|9.2.*|11.4|11.4.*|>=11.2,<12.0a0|>=11.0,<=11.6|>=11.0,<=11.5|>=11.0,<11.2']
Package libgcc-ng conflicts for:
rapids==21.12 -> cucim=21.12 -> libgcc-ng[version='>=4.9|>=7.3.0|>=9.3.0|>=9.4.0|>=7.5.0']
python==3.8 -> libgcc-ng[version='>=7.3.0']
python==3.8 -> libffi[version='>=3.2.1,<3.3.0a0'] -> libgcc-ng[version='>=4.9|>=9.4.0|>=7.5.0|>=9.3.0']
cudatoolkit=11.0 -> libgcc-ng[version='>=7.3.0|>=9.3.0|>=9.4.0']
dask-sql -> jpype1[version='>=1.0.2'] -> libgcc-ng[version='>=4.9|>=7.3.0|>=7.5.0|>=9.3.0|>=9.4.0']
Package python_abi conflicts for:
dask-sql -> importlib-metadata -> python_abi[version='2.7.*|3.10.*|3.7|3.6.*|3.6',build='*_cp27mu|*_cp36m|*_cp310|*_pypy37_pp73|*_pypy36_pp73']
dask-sql -> python_abi[version='3.7.*|3.9.*|3.8.*',build='*_cp39|*_cp37m|*_cp38']
Package python conflicts for:
dask-sql -> python[version='>=3.6|>=3.7,<3.8.0a0|>=3.9,<3.10.0a0|>=3.8,<3.9.0a0']
dask-sql -> dask[version='>=2021.11.1,<=2022.01.0'] -> python[version='2.7.*|3.5.*|3.6.*|>=2.7,<2.8.0a0|>=3|>=3.10,<3.11.0a0|>=3.6.1|>=3.7|>=3.6,<3.7.0a0|>=3.5|3.4.*|3.7.*|2.7.*|>=3.5|>=3.9|3.9.*|3.8.*|>=3.5,<3.6.0a0']
rapids==21.12 -> cupy[version='>=9.5.0,<10.0.0a0'] -> python[version='3.7.*|3.8.*|>=3.10,<3.11.0a0|>=3.9,<3.10.0a0|>=3.6|>=3.6,<3.7.0a0']
python==3.8
rapids==21.12 -> python[version='>=3.7,<3.8.0a0|>=3.8,<3.9.0a0']
Package pandas conflicts for:
dask-sql -> dask[version='>=2021.11.1,<=2022.01.0'] -> pandas[version='>=0.23.0|>=0.25.0|>=1.0']
dask-sql -> pandas[version='<1.2.0|<1.2.0,>=1.0.0|>=1.0.0']
Package libstdcxx-ng conflicts for:
python==3.8 -> libffi[version='>=3.2.1,<3.3.0a0'] -> libstdcxx-ng[version='>=4.9|>=7.5.0']
python==3.8 -> libstdcxx-ng[version='>=7.3.0']
Package typing_extensions conflicts for:
dask-sql -> importlib-metadata -> typing_extensions[version='>=3.6.4']
rapids==21.12 -> cudf=21.12 -> typing_extensionsThe following specifications were found to be incompatible with your system:
- feature:/linux-64::__glibc==2.27=0
- feature:|@/linux-64::__glibc==2.27=0
- cudatoolkit=11.0 -> __glibc[version='>=2.17,<3.0.a0']
- rapids==21.12 -> cucim=21.12 -> __glibc[version='>=2.17|>=2.17,<3.0.a0']
Your installed version is: 2.27
I can install the packages specified in construct.yaml manually with no problems, so I don't think there is any conflict here at all:
conda install -y -c rapidsai -c nvidia -c conda-forge \
python=3.8 rapids=21.12 cudatoolkit=11.0 dask-sql
+1 same set of problems even with 3.7 CC: @jaimergp can you please help us out.
@jaimergp Thanks,
I was using this, https://colab.research.google.com/github/jaimergp/condacolab/blob/main/constructor-example/condacolab_constructor_tutorial.ipynb#scrollTo=RlIMzQABoone The basic demo one, and i was trying ot install tensorflow 2.8/2.7
So insdie the dependencies part I just added
- tensorflow ==2.8 line so it will have it, but it crashed [as it is oneliner change did not make a separate ipynb:),
Debug logs:
Package Version Build Channel Size
────────────────────────────────────────────────────────────────────────────────
Install:
────────────────────────────────────────────────────────────────────────────────
conda-standalone 4.12.0 ha770c72_0 conda-forge/linux-64 11 MB
constructor 3.3.1 py37h89c1867_0 conda-forge/linux-64 164 KB
Upgrade:
────────────────────────────────────────────────────────────────────────────────
ca-certificates 2020.12.5 ha878542_0 installed
ca-certificates 2022.6.15 ha878542_0 conda-forge/linux-64 149 KB
certifi 2020.12.5 py37h89c1867_1 installed
certifi 2022.6.15 py37h89c1867_0 conda-forge/linux-64 155 KB
libgcc-ng 9.3.0 h2828fa1_18 installed
libgcc-ng 12.1.0 h8d9b700_16 conda-forge/linux-64 940 KB
libgomp 9.3.0 h2828fa1_18 installed
libgomp 12.1.0 h8d9b700_16 conda-forge/linux-64 459 KB
openssl 1.1.1j h7f98852_0 installed
openssl 1.1.1q h166bdaf_0 conda-forge/linux-64 2 MB
Summary:
Install: 2 packages
Upgrade: 5 packages
Total download: 15 MB
────────────────────────────────────────────────────────────────────────────────
Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
platform: linux-64
Collecting package metadata (repodata.json): done
Solving environment: \
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abortfailed
Traceback (most recent call last):
File "/usr/local/bin/constructor", line 11, in <module>
sys.exit(main())
File "/usr/local/lib/python3.7/site-packages/constructor/main.py", line 246, in main
dry_run=args.dry_run, conda_exe=conda_exe)
File "/usr/local/lib/python3.7/site-packages/constructor/main.py", line 112, in main_build
fcp_main(info, verbose=verbose, dry_run=dry_run, conda_exe=conda_exe)
File "/usr/local/lib/python3.7/site-packages/constructor/fcp.py", line 403, in main
verbose, dry_run, conda_exe, transmute_file_type
File "/usr/local/lib/python3.7/site-packages/constructor/fcp.py", line 295, in _main
precs = list(solver.solve_final_state())
File "/usr/local/lib/python3.7/site-packages/conda/core/solve.py", line 281, in solve_final_state
ssc = self._run_sat(ssc)
File "/usr/local/lib/python3.7/site-packages/conda/common/io.py", line 88, in decorated
return f(*args, **kwds)
File "/usr/local/lib/python3.7/site-packages/conda/core/solve.py", line 818, in _run_sat
should_retry_solve=ssc.should_retry_solve
File "/usr/local/lib/python3.7/site-packages/conda/common/io.py", line 88, in decorated
return f(*args, **kwds)
File "/usr/local/lib/python3.7/site-packages/conda/resolve.py", line 1322, in solve
self.find_conflicts(specs, specs_to_add, history_specs)
File "/usr/local/lib/python3.7/site-packages/conda/resolve.py", line 352, in find_conflicts
raise UnsatisfiableError(bad_deps, strict=strict_channel_priority)
conda.exceptions.UnsatisfiableError: The following specifications were found to be incompatible with each other:
Output in format: Requested package -> Available versions
Package python conflicts for:
mamba -> python[version='>=2.7,<2.8.0a0|>=3.10,<3.11.0a0|>=3.7,<3.8.0a0|>=3.8,<3.9.0a0|>=3.9,<3.10.0a0|>=3.6,<3.7.0a0']
conda -> python[version='2.7.*|3.5.*|3.6.*|>=2.7,<2.8.0a0|>=3.10,<3.11.0a0|>=3.8,<3.9.0a0|>=3.9,<3.10.0a0|>=3.7,<3.8.0a0|>=3.6,<3.7.0a0|>=3.5,<3.6.0a0|3.4.*']
pip -> python[version='2.7.*|3.5.*|3.6.*|>=2.7,<2.8.0a0|>=3.8,<3.9.0a0|>=3|>=3.6|>=3.7|>=3.6,<3.7.0a0|>=3.7,<3.8.0a0|>=3.5,<3.6.0a0|3.4.*']
tensorflow==2.8 -> python_abi=3.8[build=*_cp38] -> python[version='3.10.*|3.7.*|3.8.*|3.9.*']
mamba -> python_abi=3.10[build=*_cp310] -> python[version='3.10.*|3.8.*|3.9.*|3.7.*|3.6.*']
conda -> pyopenssl[version='>=16.2.0'] -> python[version='3.10.*|>=2.7|>=3.6|>=3.6,<4.0|>=3.5|3.8.*|3.9.*|3.7.*']
tensorflow==2.8 -> python[version='>=3.10,<3.11.0a0|>=3.7,<3.8.0a0|>=3.8,<3.9.0a0|>=3.9,<3.10.0a0']
pip -> setuptools -> python[version='!=3.0,!=3.1,!=3.2,!=3.3,!=3.4|>=3.10,<3.11.0a0|>=3.9,<3.10.0a0|2.7.*|>=3.6']
Package pypy3.6 conflicts for:
pip -> setuptools -> pypy3.6[version='7.3.0.*|7.3.1.*|7.3.2.*|7.3.3.*|>=7.3.1|>=7.3.2|>=7.3.3']
mamba -> python[version='>=3.6,<3.7.0a0'] -> pypy3.6[version='7.3.*|7.3.0.*|7.3.1.*|7.3.2.*|7.3.3.*']
mamba -> pypy3.6[version='>=7.3.1|>=7.3.2|>=7.3.3']
conda -> pypy3.6[version='>=7.3.1|>=7.3.2|>=7.3.3']
conda -> python[version='>=3.6,<3.7.0a0'] -> pypy3.6[version='7.3.*|7.3.0.*|7.3.1.*|7.3.2.*|7.3.3.*']
Package pypy3.7 conflicts for:
conda -> python[version='>=3.7,<3.8.0a0'] -> pypy3.7[version='7.3.*|7.3.3.*|7.3.4.*|7.3.5.*|7.3.7.*']
tensorflow==2.8 -> python[version='>=3.7,<3.8.0a0'] -> pypy3.7[version='7.3.3.*|7.3.4.*|7.3.5.*|7.3.7.*']
mamba -> python[version='>=3.7,<3.8.0a0'] -> pypy3.7[version='7.3.*|7.3.3.*|7.3.4.*|7.3.5.*|7.3.7.*']
pip -> python[version='>=3.7'] -> pypy3.7[version='7.3.3.*|7.3.4.*|7.3.5.*|7.3.7.*|>=7.3.7|>=7.3.5|>=7.3.3']
conda -> pypy3.7[version='>=7.3.3|>=7.3.4|>=7.3.5|>=7.3.7']
mamba -> pypy3.7[version='>=7.3.3|>=7.3.4|>=7.3.5|>=7.3.7']
Package setuptools conflicts for:
mamba -> conda[version='>=4.8'] -> setuptools[version='>=31.0.1']
python==3.7 -> pip -> setuptools
conda -> ruamel_yaml -> setuptools
pip -> setuptools
conda -> setuptools[version='>=31.0.1']
Package _openmp_mutex conflicts for:
mamba -> libgcc-ng[version='>=9.4.0'] -> _openmp_mutex[version='>=4.5']
python==3.7 -> libgcc-ng[version='>=7.3.0'] -> _openmp_mutex[version='>=4.5']
Package wheel conflicts for:
python==3.7 -> pip -> wheel
pip -> wheel
Package python_abi conflicts for:
tensorflow==2.8 -> python_abi[version='3.10.*|3.7.*|3.8.*|3.9.*',build='*_cp38|*_cp39|*_cp37m|*_cp310']
tensorflow==2.8 -> python[version='>=3.8,<3.9.0a0'] -> python_abi[version='3.7|3.8|3.9',build='*_pypy38_pp73|*_pypy39_pp73|*_pypy37_pp73']
Package six conflicts for:
conda -> conda-package-handling[version='>=1.3.0'] -> six[version='>=1.13.0,<2.0.0|>=1.5.2']
tensorflow==2.8 -> tensorflow-base==2.8.0=cuda102py38hcbbd5f6_0 -> six[version='>=1.12']
Package certifi conflicts for:
conda -> requests[version='>=2.20.1,<3'] -> certifi[version='>=2016.09|>=2016.9.26|>=2017.4.17']
pip -> setuptools -> certifi[version='>=2016.09|>=2016.9.26']
Package libcurl conflicts for:
mamba -> libcurl[version='>=7.69.1,<8.0a0|>=7.71.0,<8.0a0|>=7.71.1,<8.0a0|>=7.75.0,<8.0a0|>=7.76.0,<8.0a0|>=7.76.1,<8.0a0|>=7.77.0,<8.0a0|>=7.78.0,<8.0a0|>=7.79.1,<8.0a0']
tensorflow==2.8 -> tensorflow-base==2.8.0=cuda102py38hcbbd5f6_0 -> libcurl[version='>=7.83.1,<8.0a0']
Package conda conflicts for:
mamba -> conda[version='4.6.*,<4.13.0|4.6.*|4.7.*,<4.13.0|>=4.7.12,<4.13.0|>=4.8|>=4.8,<4.13.0|>=4.7.12,<4.8']
condaThe following specifications were found to be incompatible with your system:
- feature:/linux-64::__glibc==2.27=0
- feature:|@/linux-64::__glibc==2.27=0
- tensorflow==2.8 -> __cuda
- tensorflow==2.8 -> tensorflow-base==2.8.0=cuda110py39h3c9bc52_0 -> __glibc[version='>=2.17']
Your installed version is: 2.27
I think it has to do with the way we are specifying the versions. Instead of using ==, use just one =.
This construct.yaml works:
name: condacolab # you can edit this if you want
version: 0.1 # increment if you change the specs, for reproducibility!
channels:
- conda-forge
specs:
- python =3.7 # Python MUST be version 3.7
- pip
- conda
- mamba # mamba is not needed but recommended
# If any of your packages pulls in cudatoolkit:
# uncomment the line below to make sure it matches
# the output of `!echo $CUDA_VERSION` on colab
# and take only the major.minor components
# Right now, Colab uses CUDA 11.0
# - cudatoolkit =11.1
# Add your dependencies below this line
# -------------------------------------
- tensorflow =2.8
# Pip dependencies are NOT recommended. If you do need them
# uncomment the line below and edit `pip-dependencies.sh`.
# post_install: pip-dependencies.sh
# do not edit below this line
# ---------------------------
installer_type: sh
I'll update the example in this repo.
cool that works for installation, I wonder why the tensorflow version still points to 2.9.1 (the current colab one instead of conda version)
should I do something more to get it working? Can you please let me know that about exposure of the packages(or overriding part )
How are you deploying the installer? With condacolab.install_from_url()? Make sure the kernel did restart.
I can't reproduce your case but found other issues. We are planning the implementation of a new approach that does not rely on the underlying Google Colab setup at all, which should be more robust (but less reusable).
ah right, I tried that way, I uploaded to a server after creating the installer (2.2gigs) and tried to do install-from_url, now have almost all pacakge conflict when Id o condacolab_install.log Can you please see this, seems more weird now
Edit: Earlier I wasn't trying to install it, it was my bad, I presumed it was going to be installed. Now it tries to install.
Alternatively if I do simple mamba install tensorflow=2.8 on a OK environment (plain condo environment I meant), the Tensorflow version points to Colab version even tho condo has Tensorflow installed. So I am confused now^^
Does it work if you install it somewhere else, as in not /usr/local?
Instead of using condacolab for this test, just do:
!wget /url/to/your/uploaded/installer.sh
!bash your_installer.sh -bfp /opt/conda
and let's see if that works.
Yes, it do crash as expected, attached logs here, manual_bash.log
Edit: just to be clear on how I made the *.sh file is, I just added tensorflow 2.8 as a conda dep, and it generated .sh file,, and trying to do the bash invocation for the file as you advised.
Thanks for the extra info. I'll try to look into this but my time is limited lately. We are working on a different approach too, as I said earlier, so there's a chance that the new attempt is more robust and we skip this problem altogether. I am also working on constructor itself to prevent those solving errors which shouldn't be there to begin with.
Interesting, thanks for update,
Another update I have is, If I do a simple condacolab setup and install tensorflow on it with mamba after runtime restart, I am able to get it crashing with glibc mismatch error :),
So that means, on plain conda + manual installation of TF with !mamba install tensorflow=2.7 actually installs (or uses the condalab's version with mismatched glibc),
After we solve the above conflict error, I guess it will boil down to this problem,
Also, I tried installing relevant glibc with mamba ie. with !mamba install -c conda-forge gxx_linux-64==11.1.0 libstdcxx-ng>=12.1 did not help,
Second thing is, also I tried to manually install glibc in system and tried to play with some linkage from usr/lib/x86_64-linux-gnu/libstdc* to /usr/local/lib/libstdc* but tensorflow still do not like it. Note that if i check manually with strings of glibc versions, I could find the version whicht ensorflow is searching
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
[/usr/local/lib/python3.7/site-packages/tensorflow/python/pywrap_tensorflow.py](https://localhost:8080/#) in <module>
63 try:
---> 64 from tensorflow.python._pywrap_tensorflow_internal import *
65 # This try catch logic is because there is no bazel equivalent for py_extension.
ImportError: /usr/local/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/local/lib/python3.7/site-packages/tensorflow/python/../../../../libgrpc.so.21)
During handling of the above exception, another exception occurred:
ImportError Traceback (most recent call last)
3 frames
[<ipython-input-13-d6579f534729>](https://localhost:8080/#) in <module>
----> 1 import tensorflow
[/usr/local/lib/python3.7/site-packages/tensorflow/__init__.py](https://localhost:8080/#) in <module>
39 import sys as _sys
40
---> 41 from tensorflow.python.tools import module_util as _module_util
42 from tensorflow.python.util.lazy_loader import LazyLoader as _LazyLoader
43
[/usr/local/lib/python3.7/site-packages/tensorflow/python/__init__.py](https://localhost:8080/#) in <module>
38 # pylint: disable=wildcard-import,g-bad-import-order,g-import-not-at-top
39
---> 40 from tensorflow.python import pywrap_tensorflow as _pywrap_tensorflow
41 from tensorflow.python.eager import context
42
[/usr/local/lib/python3.7/site-packages/tensorflow/python/pywrap_tensorflow.py](https://localhost:8080/#) in <module>
78 except ImportError:
79 raise ImportError(
---> 80 f'{traceback.format_exc()}'
81 f'\n\nFailed to load the native TensorFlow runtime.\n'
82 f'See https://www.tensorflow.org/install/errors '
ImportError: Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 64, in <module>
from tensorflow.python._pywrap_tensorflow_internal import *
ImportError: /usr/local/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/local/lib/python3.7/site-packages/tensorflow/python/../../../../libgrpc.so.21)
Failed to load the native TensorFlow runtime.
See https://www.tensorflow.org/install/errors for some common causes and solutions.
If you need help, create an issue at https://github.com/tensorflow/tensorflow/issues and include the entire stack trace above this error message.
---------------------------------------------------------------------------
NOTE: If your import is failing due to a missing package, you can
manually install dependencies using either !pip or !apt.
To view examples of installing some common dependencies, click the
"Open Examples" button below.
---------------------------------------------------------------------------
Basically what I am trying to do is, creating a developer environment with pinned version of TF and some other libraries within colab so even if Google arbitrarily updates library and break things, we will still have working env because it is manual pinned versions.
Yes, I ran into that too. It's not about what runtimes installed, but how the packages that depend on them are compiled. I am assuming our overwriting of /usr/local is not perfect and we are leaving some original Colab libraries in there that depend on other stuff. So we are mixing conda files with colab files and that's just like flipping a coin.
The cleaner approach we are working on consists of:
- Forget about the packages preinstalled in colab
- Install miniconda/miniforge/whatevs to a non
/usr/locallocation (e.g./opt/conda) - Patch
/usr/local/pythonso it becomes a bash script that activates the/opt/condainstallation and thenexecs conda'spython. Activation should clean most of the env vars that cause trouble with the system, but we might need to do some more patching here. - Profit?
Also, I might need to rebuild the installers condacolab uses by default. They might be too old to just install things on top? No clue.
Yes that sounds like a great plan and would love some setup like that. If we manage to do things then just zipping /opt/conda and then a simple script to activate that (4) would be ideal scenario for an end-user. But we need to make sure the libs we install are statically linked (or alteast within /opt/conda alone) which might be bit annoying thing to do.
Also, after doing some stuff like i said above, restart of runtime manged to kick in old-version of Tensorflow, currently trying to see if we can have it within construct.yaml file instead of doing runtime deps which i am not sure.
Okay an update now, with these packages,
- tensorflow =2.8
- gxx_linux-64 =11.1.0
- libstdcxx-ng >=12
I am able to get tensorflow 2.8.2 working within curent running runtime and !constructor . did indeed create .sh file. ideally, now just need to figure out a way to get it installed during runtime of a Colab instance from url or from file or by any means.
Did not require to hack with librareis/and other things to get this working. So that is a good sign:)
I am now wondering whether the packaging problem is how the == is used instead of = from constructor and failing (similar to the ealrier conflict errors)
Yes, == is exact match so ==2.8 means that we MUSt find tensorflow with version 2.8 strictly. If we have 2.8.0 that's not a match. In contrast, =2.8 translates to ==2.8.* (any version with major 2 and minor 8), which is more flexible and usually what people really mean.
So yes, let's stick to = and forget about ==.
now just need to figure out a way to get it installed during runtime of a Colab instance from url
I am curious why you need this at runtime. Creating the constructor installer is meant as a way to cache the solve and reduce install times. The idea is to store it somewhere (e.g. GH releases) and then call install_from_url() on a new notebook. If you just want to install something at runtime reproducibly, you can generate a lock file with conda list --explicit > lockfile.conda and then keep the output somewhere safe. This file can be used with conda install --file lockfile.conda.
Alternatively, you can use conda-lock which improves this manual process a lot.
I am curious why you need this at runtime. Hi, the idea is to cache and have a fast-return to locked-runtime for Conda in Google Colab rather than downloading and setting up which takes ~12-14minutes.
I found about condaclab from https://stackoverflow.com/questions/64464195/how-to-install-conda-on-google-drive-for-google-colab The answer from Alex seems to be working given that I install the library headers(gcc/gxx) with apt and remove the system tensorflow and others python packages related to conda env. Just that I require to tar it and untar it at runtime. So if we get it wokring via condacolab it will be fast and easier in one step process I guess.
@ssurbhi560 is working on the fully isolated approach so hopefully we won't need to deal with all those workarounds.
Hi @vibhoothi, #31 is merged. Check the prerelease with !pip install -q https://github.com/conda-incubator/condacolab/archive/main.tar.gz and let us know it goes!