Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to resolve 'conda not found' error with a miniforge environment #802

Closed
kburchfiel opened this issue Mar 20, 2024 · 8 comments
Closed

Comments

@kburchfiel
Copy link

kburchfiel commented Mar 20, 2024

I would like to use a miniforge Python environment within JupyterLab Desktop on Ubuntu. Therefore, I added the path to this environment (/home/my_username/miniforge3/envs/custom_env/bin/python3.12) into the 'Use custom Python environment' field within JupyterLab Desktop's 'Manage Python environments' menu.

I know that I also need to add an entry into the 'conda path' field. My root miniforge3 folder (which includes all of my environments) contains a 'conda' file within the 'bin' folder that contains the following text:

#!/home/my_username/miniforge3/bin/python
# -*- coding: utf-8 -*-
import sys
# Before any more imports, leave cwd out of sys.path for internal 'conda shell.*' commands.
# see https://github.com/conda/conda/issues/6549
if len(sys.argv) > 1 and sys.argv[1].startswith('shell.') and sys.path and sys.path[0] == '':
    # The standard first entry in sys.path is an empty string,
    # and os.path.abspath('') expands to os.getcwd().
    del sys.path[0]

if __name__ == '__main__':
    from conda.cli import main
    sys.exit(main())

However, when I enter the path to this file (/home/my_username/miniforge3/bin/conda) into the 'conda path' , I subsequently receive the following error message when trying to open JupyterLab Deskop:

"conda not found"
conda executable not found. Please set conda path in settings to use the conda sub environment."

This indicates that I'm entering the wrong path, but I'm not sure what I should use instead. Interestingly, I don't see a condabin/conda file within the folder for the environment that I wish to use. I don't think that's the source of the issue, though, since when I changed the custom environment entry from my custom environment to my main miniforge3 Python environment, I continued to receive an error message.

I also tried entering /home/my_username/miniforge3/condabin/conda as the path, but this didn't work either.

Thank you in advance for helping me figure out how to get JupyterLab Desktop to accept my custom conda path!

Copy link

welcome bot commented Mar 20, 2024

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
welcome
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

@kburchfiel
Copy link
Author

kburchfiel commented Mar 21, 2024

I installed JuptyerLab's bundled Python environment to see if it would allow me to run Python instead. Interestingly, once I installed it, I was able to open up a notebook and run it using my custom environment, even though there still wasn't a conda path specified within the settings menu. (This switch involved setting both the environment, near the top right of the program, and the kernel, located a bit below the environment, to my custom Conda environment.)

This solution works fine for me, although I do have one follow-up question: does the bundled environment use Anaconda? Anaconda updated its terms of service to require payments for commercial use in certain cases (which is why I switched over to miniforge), so I wanted to make sure that installing this environment wouldn't require me to make payments to Anaconda.

@JasonWeill
Copy link

@mbektas Can you answer this question about whether the bundled Python environment uses Anaconda, and if so, what changes customers need to make to use alternatives such as miniforge?

@mbektas
Copy link
Member

mbektas commented Mar 27, 2024

@kburchfiel the bundled environment is a conda environment (generated using miniconda). We use conda-forge channel by default for bundling the environment and for new environments created by the app. These make sure the app complies to Anaconda rules. @bollwyvl did you have any other details to share on this matter?

@kburchfiel
Copy link
Author

@mbektas That's very helpful to know, thank you! So just to confirm, I don't need to pay Anaconda to use JupyterLab Desktop's bundled environment, correct? (I'm guessing that's what you meant by 'complies to Anaconda rules.')

@mbektas
Copy link
Member

mbektas commented Mar 27, 2024

yes, (as far as I know) you don't need to pay to Anaconda to use JupyterLab Desktop and the bundled environment. You can check this Anaconda blog post which supports that too.

@bollwyvl
Copy link
Contributor

disclaimer: former employee of Anaconda, Inc. ne Continuum Analytics

Here is the conda-forge take on it:

https://conda-forge.org/blog/2020/11/20/anaconda-tos/

To my understanding, and IANAL, what are encumbered are the non-free, mostly repackaging of (mostly) conda-forge feedstocks:

  • miniconda
    • this includes the one GitHub re-distributes on their runners, etc.
  • the "Anaconda individual" distribution
  • anaconda navigator
  • anything downloaded from anaconda.com
    • might even include repodata.json, dunno
  • anything downloaded from:
    • anaconda.org/defaults
    • anaconda.org/msys2

I therefore generally recommend avoiding all of the above by open source projects, and by extension, corporate downstreams that are looking at this stuff.

Other conda-compatible distributions built on miniforge, (e.g. mambaforge), micromamba, pixi distributions are not encumbered by the Anaconda, Inc. ToS, and are fully bootstrapped from the repos on https://github.com/conda-forge. This includes the conda-forge/m2-* packages, needed to bootstrap the free POSIX environment on win-64.

Of course, on non-free platforms/compilers (osx-?, win-64) it isn't always 100% clear what your rights are regarding binary packages. And further, of course, this also ships basically an operating system (chromium) and another language runtime (nodejs), good luck untangling what exactly is in those, if you actually need to audit what licenses are coming in. I basically guarantee there's some (A)GPL code lighting up before you start a kernel, but definitely once you start doing any real compute. So don't go white-label reselling this stuff.

@kburchfiel
Copy link
Author

Thanks so much for the confirmation and detailed explanations, @mbektas and @bollwyvl!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants