Съобщение за грешка на Dyld при стартиране на PyCharm

1. Нещо може да се повреди с моите виртуални среди

Най-лесното решение е използването на venv - това е стандартна библиотека и следователно най-добрата базова линия за виртуални среди. (За изчерпателност си струва да споменем, че исторически е имало редица решения за това.) Като пример създаването на venv с GUI на PyCharm е лесно, то създава нов интерпретатор от базов интерпретатор на Python, по желание споделящ своите пакети за сайт. GUI ви позволява да взаимодействате с PyPI за инсталиране на допълнителни пакети.

В крайна сметка си струва да се научите да правите същото с помощта на командния ред, вижте venv — Създаване на виртуални среди. Това се свежда до 3 команди

1. Създайте venv (тъй като имате Python на вашия PATH)

   c:\>python -m venv c:\path\to\myenv

2. Активирайте venv (това е специфично за ОС, вижте документацията)

   <venv>/bin/activate

3. След активиране използвайте pip, за да инсталирате библиотеките, които искате

   pip install library_name

След като venv бъде създаден и активиран, той е готов за използване на терминала (вътре или извън PyCharm) или можете да го използвате с изпълнете конфигурации в PyCharm.

Сега във вашия случай вие също използвате Anaconda, която управлява пакетите и средите вместо вас. Но е важно да разберете, че това, което Anaconda прави в по-голямата си част, са горните стъпки, обвити в нейния собствен GUI, вижте приликите с Намиране на вашия път за интерпретатор на Anaconda Python.

Освен това има строго правило, че venvs не трябва да се копират или преместват. Те имат твърдо кодирани пътеки вътре в тях, които ще се счупят. Така че, когато създавате venv, използвайте го в директорията, в която сте го създали. Целият смисъл на venvs е, че ако счупите нещо, вие просто създавате ново в движение. В крайна сметка ще искате да напишете свой собствен shell скрипт, за да автоматизирате създаването на venvs.

2. Нещо може да е счупено с моя PATH

PATH=
/Library/Frameworks/Python.framework/Versions/3.9/bin:
/Library/Frameworks/Python.framework/Versions/3.9/bin:
/Library/Frameworks/Python.framework/Versions/3.9/bin:
/Library/Frameworks/Python.framework/Versions/3.9/bin:
/Users/my_name/opt/anaconda3/bin:
/Users/my_name/opt/anaconda3/condabin:
/anaconda3/bin:
/Library/Frameworks/Python.framework/Versions/3.6/bin:
/Library/Frameworks/Python.framework/Versions/3.6/bin:
/Library/Frameworks/Python.framework/Versions/3.6/bin:
/Library/Frameworks/Python.framework/Versions/3.6/bin:
/usr/local/bin:
/usr/bin:/bin:
/usr/sbin:
/sbin:
/Library/TeX/texbin:
/Library/Apple/usr/bin

В macOS/Linux двоеточие : се използва като разделител на пътя. Така че, ако разделим вашата променлива на средата PATH на отделни редове, ще видим, че имате повторени Python 3.9 и Python 3.6 (може да са различни микро версии, проверете, като стартирате изпълнимия файл във всяка директория с python --version). Значението на имената на пътищата е добре обяснено в 4 . Използване на Python на Macintosh

За да избегна объркване, имам само най-новата версия на Python на моя PATH. Всяка друга базова версия на Python, от която се нуждая, се избира прозрачно чрез активиране на правилния venv.

Имате и bin пътищата към Anaconda, проверете вътре в тях, за да видите какво прави Anaconda изпълним файл. Освен това имате нормалните неща за ОС на /Library/Apple/usr/bin, които не трябва да пречат на нищо, свързано с разработката на Python.

И накрая, откриването на модули е по-динамично от това, което е във вашия PATH. Пътят за търсене на модул sys.path се попълва с път, откъдето изпълнявате скрипт, което означава, че всеки модул/пакет на directory\where_you_execute\python your_script.py е откриваем (можете да го проверите по време на изпълнение).

3. Нещо може да се повреди при опит за управление на множество версии на Python на моя компютър

Ето къде става сложно. Ако работите с различни преводачи, версии на пакети и т.н... В крайна сметка ще искате да получите инструмент на трета страна, който помага да управлявате всичко това, което би било Anaconda или Virtualenv или Поезия или т.н... Но по същество всичко това, което правят, е да управляват venvs, добавяйки функционалност и сложност, важно е да научите как да създавате и управлявате venvs ръчно, за да разберете по-добре какво правят тези инструменти за вас.

И накрая, самата IDE на PyCharm е внедрена в Java. Когато стартирате IDE, той има свой собствен изпълним файл и е рядък случай нещо свързано с интерпретатор на Python да накара IDE да се срине при стартиране. От друга страна знаете, че виновникът е един от вашите интерпретатори на Python, а именно от съобщението за грешка:

Python Version: 3.6.4 (3.6.4)

и конкретната грешка казва всичко (или файловете са били преместени, или някаква грешка е прекъснала връзките):

Причина: изображението не е намерено.

Ако не можете да стартирате IDE, за да разрешите проблема отвътре, отървете се от всякакви препратки към проблемния интерпретатор като редактирате конфигурационните файлове . Не знам как да направя това точно, но ако използвате Anaconda, трябва да е възможно да стартирате GUI на Anaconda извън IDE, за да се отървете и от проблемния интерпретатор.

Като странична бележка, ако срещнете проблеми поради наличието на няколко интерпретатора на PATH, използвайте командата which python на bash или < команда href="https://ss64.com/nt/where.html" rel="noreferrer">where python в Windows. Това, което ще ви каже, е кой интерпретатор на Python на вашия PATH се извиква, когато вие или някое приложение изпълните python something на командния ред.

Не мисля, че този въпрос (или другите свързани въпроси) имат достатъчно информация, за да диагностицират напълно проблема. Това ще изисква задълбочен преглед на точното Конфигурации на Anaconda - но същата грешка беше докладвана и от потребителите на brew.

Най-вероятният сценарий е, че когато стартирате PyCharm, списъкът с интерпретатори се попълва и това извиква Anaconda. В един момент след надграждане до най-новата версия на Python една от съществуващите среди се разпадна в синхрон, защото се разреши на предишен базов интерпретатор на PATH (вместо да бъде твърдо кодиран към конкретна инсталация.) Нещо трябва да се е объркало чрез несъвместимост между пакети, която изисква обща актуализация, нещо е изтрито или просто е кеширано, което се нуждае от изчистване.