PIP / PYTHON: Normale site-pakketten is niet beschrijfbaar

Ik heb een nieuwe MacBook – een gebruiker geïnstalleerd, en vervolgens installeerde ik een nieuwe gebruiker (de mijne), verleende admin-privileges en verwijderde de oude. Ik ben op OS Catalina.

Sinds de installatie heb ik verschillende toestemmingsproblemen gehad.
VSCODE kan geen jupyter notebook vinden, pipInstalleert pakketten op ~/Library/Python/3.7/site-packages.

Wanneer ik which python3Ik krijg usr/bin/python3.
Wanneer ik doe pip3 install <package>IK KRIJGEN: Defaulting to user installation because normal site-packages is not writeableen dan staat het al Ik kan het niet openen als ik het doe import <package>.

Het lijkt duidelijk dat dit een toestemmingsprobleem is, pipkan niet installeren op de “basis” python, en ze pythonkan niet vinden wat ik heb geïnstalleerd in ~/Library/Python/3.7/site-packages.

Ik heb geprobeerd het besturingssysteem opnieuw te installeren, maar omdat ik geen schone installatie heb gedaan, veranderde het niets.
Wat mis ik?
Hoe kan ik machtigingen oplossen? Waar wil ik Pakketten die moeten worden geïnstalleerd (venvzeker, maar sommige pakketten wil ik Global (zoals jupyter).


Antwoord 1, Autoriteit 100%

Als @tomdegeus vermeld in de opmerkingen, werkt deze opdracht voor mij:

Python 3:

python3 -m pip install [package_name]

Python 2:

python -m pip install [package_name]

Antwoord 2, Autoriteit 52%

Het is het beste om het systeem-verstrekte Python rechtstreeks niet te gebruiken. Verlaat deze alleen omdat het OS het in ongewenste manieren kan veranderen, zoals u heeft ervaren.

Het beste is om uw eigen Python-versie(s) te configureren en deze per project te beheren met behulp van virtualenv(voor Python 2) of venv(voor Python 3). Dit elimineert alle afhankelijkheid van de door het systeem geleverde Python-versie en isoleert ook elk project van andere projecten op de machine.

Elk project kan indien nodig een andere Python-puntversie hebben en krijgt zijn eigen site_packages-directory, zodat pip-geïnstalleerde bibliotheken ook verschillende versies per project kunnen hebben. Deze aanpak is een grote probleemvermijder.


Antwoord 3, autoriteit 24%

python3.7 -m pip install [package_name]

(u moet natuurlijk de versie gebruiken die u heeft)

heeft het voor mij opgelost.

Het meest gestemde antwoord python3 -m pip install [package_name]helpt me hier niet.

In mijn geval werd dit veroorzaakt door een conflict met de dominante 3.6-versie die ook standaard was geïnstalleerd. Je vraagt je misschien af waarom je 3.6 op je systeem hebt staan, die versie ga je nu waarschijnlijk niet meer gebruiken. De reden is dat 3.6 wordt gebruikt als een onafhankelijke standaard python-versie voor veel pakketinstallatieprogramma’s. Die installateurs willen niet controleren welke individuele versie je gebruikt en of dat past, ze gebruiken gewoon 3.6 als standaard, of je dat nu leuk vindt of niet.

Hier is een voorbeeld van --upgrade pip:

pip3 install --upgrade pip

Standaard ingesteld op gebruikersinstallatie omdat normale sitepakketten niet beschrijfbaar zijn
Aan eis al voldaan: pip in
/home/USERNAME/.local/lib/python3.6/site-packages (20.3.1)

python3 -m pip install --upgrade pip

Standaard ingesteld op gebruikersinstallatie omdat normale sitepakketten niet beschrijfbaar zijn
Aan eis al voldaan: pip in
/home/USERNAME/.local/lib/python3.6/site-packages (20.3.1)

python3.7 -m pip install --upgrade pip

Pip verzamelen
Deserialisatie van cache-invoer mislukt, invoer genegeerd
In de cache opgeslagen https: //files.pythonhosted.org/packages/ab/11/2dc62c5263d9eb322f2f028f7b56cd9d096bb8988fcf82d65fa2e4057afe/pip-20.3.1-py2.py3-none-any.whl
Verzamelde pakketten installeren: pip pip-20.3.1 succesvol geïnstalleerd


Antwoord 4, autoriteit 8%

Het gebeurt bij mij wanneer ik de mapnaam van de virtuele omgeving was: venv.

in dit geval geeft het fouten zoals:

No module pip

Default folder is unwritable

het hernoemen van de map lost het probleem op.


Antwoord 5, autoriteit 4%

sudo pip install

Werkte voor mij. Maar pip install wordt niet aanbevolen om met sudo te worden uitgevoerd. Het probleem waarmee ik op BIGSUR werd geconfronteerd, was dat het systeempython gebruikte. Zodra ik python 3.9 heb geïnstalleerd met

brew install [email protected]

Toen werkte pip prima


Antwoord 6

Heb hetzelfde probleem gehad bij een nieuwe installatie van Debian 9.12.
Het opnieuw opstarten van mijn server loste het probleem op.


Antwoord 7

in mijn geval heeft python3 -m pip install [package_name]dat niet opgelost.
in mijn geval was het een probleem met betrekking tot andere processen die de directory bezetten.
Ik herstart Pycharm en sluit elk ander programma dat deze map zou kunnen bezetten, en installeerde het pakket opnieuw in de map site-packages met succes.


Antwoord 8

Ik gebruik Anaconda op Ubuntu en had hetzelfde probleem. Ik heb het opgelost door de volgende stappen te volgen:

huidige omgeving deactiveren

conda deactivate

Vervolgens wordt de basisomgeving geactiveerd. Ik heb ook de basisconda-omgeving gedeactiveerd. Hiervoor heb ik conda deactivateopnieuw gebruikt.

Ten slotte activeer ik mijn projectomgeving rechtstreeks (in plaats van te activeren vanuit de basisomgeving) door het volgende commando. Daarna heb ik het beoogde pakket met succes geïnstalleerd en werkte perfect.

conda activate myenv
pip install somepackage

Antwoord 9

Toen dit probleem bij me opkwam, heb ik alle genoemde benaderingen geprobeerd, maar ze lijken niet te werken.

In plaats daarvan deed het herstarten van de Python-taalserver in mijn VSCode het werk – mijn SimPy-pakket is nu gevonden. Op Mac is dit Cmd+Shift+Pen selecteer “Python: Restart Language Server”.

Other episodes