2016-03-10 19 views
8

Mam dziwne zachowanie tutaj:Django 1.9a1 __init__.py jest widoczny w Eclipse/PyDev chociaż powinny być usunięte (Windows)

Właśnie zmodernizowane do Django Django 1.9a1 1.9.4 z użyciem pypeć. Instalacja poszła dobrze, a Django działał sprawnie, ale podczas uruchamiania nadal wyświetlał numer wersji "1.9a1".

Tylko po to, aby odinstalować Django ponownie za pomocą pip i potwierdzić, że moje foldery django nie istnieją w C: \ Program Files (x86) \ Python 3.5 \ lib \ site-packages (ani "django", ani Folder "Django-1.9.4").

Po ponownym uruchomieniem serwera, byłem zaskoczony, aby przeczytać komunikat o błędzie

from django.core.management import execute_from_command_line 
File "C:\Program Files (x86)\Python 3.5\lib\site-packages\django\__init__.py", line 1, in <module> 
from django.utils.version import get_version 
ImportError: No module named 'django.utils' 

Spodziewałem błąd być coś jak „pakiet nie znaleziono Django” lub podobne. Od zaćmienie zapewnia nazwę pliku jako odnośnik, kliknąłem na to zaćmienie otwarciu pliku z zawartością

from django.utils.version import get_version 
VERSION = (1, 9, 0, 'alpha', 1) 
__version__ = get_version(VERSION) 
[...] 

dwukrotnym sprawdzeniu, że plik nie jest dostępny poprzez linię poleceń i za pomocą programu Windows Explorer.

Gdzie znajduje się ten plik i jak się go pozbyć? Czy jest generowany automatycznie (a jeśli tak, jak mogę poprawić ten mechanizm)

Czy brakuje mi czegoś całkowicie oczywistego?

Dodatkowe informacje: I ponownie zainstalowane Django 1.9.4 i startowych .py plik znajduje się w katalogu C:. Program Files \ (x86) \ Python 3.5 \ lib \ site-packages \ django__init __ py pokazuje poprawną wersję info. Ale jeśli uruchomię projekt Django, podana informacja o wersji to 1.9a1.

Nawet kiedy otworzyć wiersz i wpisz cmd

python -c "import django; print(django.get_version())" 

odpowiedź jest 1.9a1

Aktualizacja 13.03.2016 17:57: znowu odinstalowane i wykorzystywane wyraźnej == 1,9 .4 zasugerowane przez alecxe. Ten rozwiązał część problemu: Teraz, jeśli mogę otworzyć wiersz polecenia,

python -c "import django; print(django.get_version())" 

daje mi poprawną odpowiedź (1.9.4). Ale w Eclipse/PyDev mój projekt już się nie rozpoczyna. Pierwszy komunikat o błędzie:

Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x03F72108> 
Traceback (most recent call last): 
    File "C:\Program Files (x86)\Python 3.5\lib\site-packages\django\apps\config.py", line 118, in create 
    cls = getattr(mod, cls_name) 
AttributeError: module 'django.contrib' has no attribute 'admin' 

Oczywiście, moduł admin jest istniejący w systemie plików.

Wystarczy sprawdzić, zacząłem nowy projekt w konsoli przy użyciu

django-admin startproject mysite 

a nowy projekt zostanie pomyślnie utworzony.

Kiedy używam PyDev wewnątrz Eclipse, aby rozpocząć nowy projekt (używając "new"/"PyDev Django Project"), proces się nie powiedzie! Katalog projektu, jak również plik manage.py, są tworzone, ale katalog projektu jest pusty (no init .py, settings.py, urls.py, wsgi.py).

Wygląda na to, że Eclipse/PyDev nie używa poprawnej instalacji django, mimo że wszystkie podane nazwy plików są poprawne. Czy jest w tym przypadku jakieś buforowanie? I tak, ponownie uruchomiłem Eclipse po ponownej instalacji.

Dodatkowe informacje 2016-03-14 17:44: Po prostu ponownie uruchomiłem komputer i, co zaskakujące, moje eclipsy były teraz w stanie ponownie uruchomić mój projekt - powyższy błąd zniknął, ALE wyświetlany numer wersji django to 1.9a1 ponownie! Teraz uruchomiłem wiersz polecenia i python -c "import django; print(django.get_version())" dał mi ponownie 1.9a1! Co zrobiłem następnie było ponowne uruchomienie wiersza poleceń jako administrator i - tataa - dostałem 1.9.4.

Problem wydaje się być związany z uprawnieniami administratora, które mogą wynikać z zainstalowania Pythona w wersji C:\Program Files (x86)\Python 3.5. Użyłem okna konsoli z uprawnieniami administratora dla wszystkich instalacji/odinstalowań instalacji pip opisanych powyżej. Czy istnieje jakiś mechanizm okna, który mógłby wyjaśnić to zachowanie?

Rozwiązanie 14.03.2016 18:17: teraz szukał całe dysku C: dla folderów zawierających "Django", i znalazłem jeden w

C:\Users\[my_username]\AppData\Local\VirtualStore\Program Files (x86)\Python 3.5\Lib\site-packages\django

i - niespodzianka - zawiera plik init o nieprawidłowym numerze wersji. Wygląda na to, że zainstalowałem wersję 1.9a1 bez uprawnień administratora, a Eclipse zawsze używa tej wersji, ponieważ jest uruchamiana bez uprawnień administratora. Po kilku badaniach dotyczących Windows VirtualStore postanowiłem ręcznie usunąć cały folder C:\Users\[my_username]\AppData\Local\VirtualStore\Program Files (x86)\Python 3.5.

Natychmiast po tym, moje cmd-window pokazało mi wersję 1.9.4, niezależnie od trybu administratora lub nie-administratora. I - co najważniejsze - kiedy uruchomiłem mój projekt django w czasie zaćmienia, pokazał on również prawidłowy numer wersji. Dla pewności, stworzyłem nowy projekt django za pomocą kreatora PyDev, a wszystkie pliki projektu zostały utworzone poprawnie.

Podsumowując, problem był spowodowany poprzednią instalacją django bez uprawnień administratora, po której następowała instalacja django z uprawnieniami administratora. Odpowiedzialnym mechanizmem był Windows VirtualStore, a nie Eclipse lub PyDev.

Zostawię cały opis mojego Odyseia, tak jak być może pomoże to komuś znaleźć temat. Poniżej przedstawię krótką odpowiedź podsumowującą.

Odpowiedz

4

Długa historia jest opisana powyżej, Krótka odpowiedź brzmi:

miałem dodatkową instalację Django w moim folderze C:\Users\[my_username]\AppData\Local\VirtualStore\Program Files (x86)\Python 3.5\Lib\site-packages\django. Wynikało to z zainstalowania wersji 1.9a1 bez uprawnień administratora.

Od czasu, gdy eclipse uzyskiwał dostęp do django również bez uprawnień administratora, używał przestarzałej wersji, a nie ostatniej, która została zainstalowana za pomocą pip z prawami administratora.

Usunąłem folder C:\Users\[my_username]\AppData\Local\VirtualStore\Program Files (x86)\Python 3.5 i po ponownym uruchomieniu zaćmienia wszystko działało.

+0

Interesująca historia - dzięki za udostępnienie! Zostawię odpowiedź na wypadek, gdyby ktoś miał podobny problem w przyszłości. – alecxe

+0

Należy to naprawić w 32-bitowej wersji 3.5.1 (programy 64-bitowe nigdy nie zostały naruszone). Początkowa wersja 3.5 nie została poprawnie zamanifestowana, ale instalacje potokowe 3.5.1 powinny zakończyć się niepowodzeniem, jeśli nie można uzyskać dostępu do pakietów witryny, zamiast przekierowywać je do katalogu 'VirtualStore' użytkownika. – eryksun

+0

dzięki za informacje erkyksun! Myślę, że zrobiłem starą instalację przy użyciu wersji 3.5.0 i pamiętam, że nie udało mi się zainstalować z nowszymi wersjami Pythona. Mam więc nadzieję, że nie ma na to tak wielu ludzi. I dobrze jest wiedzieć, że problem został rozwiązany. – OBu

1

co pamiętam pomógł mi w podobnym przypadku była odinstalowanie Django całkowicie i instalowanie go ponownie:

pip uninstall django 
pip install django==1.9.4 

Być może trzeba sprawdzić i usunąć ręcznie django katalog i plik jaj, jeżeli jest pozostawione w katalogu C:\Program Files (x86)\Python 3.5\lib\site-packages po odinstalowaniu django przez pip.

+0

Zrobiłem tak wcześniej, ale bez "== 1.9.4" - z twoją wersją, otrzymałem prawidłowy numer wersji w linii poleceń, ale mój projekt nie jest już uruchamiany: Nieobsługiwany wyjątek w wątku rozpoczęty przez < funkcja check_errors. .wrapper przy 0x03F72108> Traceback (ostatnie ostatnie połączenie): Plik "C: \ Program Files (x86) \ Python 3.5 \ lib \ site-packages \ django \ apps \ config.py", linia 118, w utworzeniu cls = getattr (mod, cls_name) AttributeError: moduł "django.contrib" nie ma atrybutu "admin" Kiedy sprawdzam system plików, contrib zawiera folder administracyjny z wszystkimi potrzebnymi plikami. – OBu

+0

@OBu dzięki za wypróbowanie tego. Czy na pewno plik wykonywalny 'pip' w twoim przypadku odnosi się do' pip' zainstalowanego w środowisku Python 3.5? – alecxe

+0

'gdzie pip' daje mi C: \ Program Files (x86) \ Python 3.5 \ Scripts \ pip.exe - który jest moją instalacją python 3. I mam tylko jedną instalację pythona (bez virtualenv, bez python 2, ...). BTW: Zaktualizowałem nieco pytanie, aby odzwierciedlić najnowsze rzeczy, które wypróbowałem. – OBu

Powiązane problemy