Python: brak modułu o nazwie datetime?

56

System operacyjny: Ubuntu 14.04 LTS

Python: 2.7.6

Moja instalacja Gourmet Recipe Manager nagle przestała się ładować. Po uruchomieniu w oknie terminala na końcu śledzenia pojawia się następujący komunikat:

import datetime as dt
ImportError: No module named datetime

O ile wiem, nic się nie zmieniło, a moja instalacja w Pythonie jest aktualna. Po prostu przestało działać wczoraj. Z pewnością docenię dobre podejście do diagnozowania i rozwiązywania tego problemu!

Aktualizacja: dziękuję wszystkim, którzy odpowiedzieli!

Tim, przepraszam, jeśli zadałem to pytanie w niewłaściwym miejscu. Wykreśl to, że jesteś nowym facetem, który po prostu korzysta z linków z witryny Ubuntu.

TheSchwa, próbowałem twojej sugestii i otrzymałem taki sam komunikat o błędzie jak powyżej.

muru, pakiet wydaje się być zainstalowany, ale nie mam pojęcia, czy jest poprawnie zainstalowany / skonfigurowany. Jak mogę się dowiedzieć?

Przepraszam za wszystkie pytania, ale jestem starym facetem RedHata, który od dłuższego czasu nie ma Linuksa. Wszystkie rzeczy apt / dpkg są dla mnie nowe.

Joe
źródło
Chociaż jest to (tylko) temat tutaj, możesz uzyskać lepszą odpowiedź na temat przepełnienia stosu . Nie mogę też tego odtworzyć. W ogóle żadnych błędów, przy tym samym ustawieniu co ty ...
Tim
Co się stanie, jeśli spróbujesz import datetimew interprecie Pythona? Możesz uruchomić tłumacza, otwierając terminal i wykonując polecenie python. Możesz to zostawić Ctrl+d.
TheSchwa,
Zgodnie z dpkg -S $(python -c "import datetime; print datetime.__file__")tym moduł datetime pochodzi z libpython2.7-stdlibpakietu. Czy ten pakiet jest poprawnie zainstalowany? Czy możesz spróbować zainstalować ponownie?
muru
Okej, więc konkretny plik to /usr/lib/python2.7/lib-dynload/datetime.x86_64-linux-gnu.soten plik? Czy widzisz również /usr/lib/python2.7/lib-dynloadwymienione w danych wyjściowych z echo $(python -c "import sys; print sys.path")? Btw system wymiany stosów tak naprawdę nie powiadamia komentujących podczas edytowania postu; więc przynajmniej zawsze publikuj szybki komentarz, taki jak „Zaktualizowałem pytanie o informacje”, abyśmy otrzymali powiadomienie z
prośbą
Zaktualizowano pytanie o informacje. Dzięki, TheSchwa! Moje odpowiedzi brzmią odpowiednio: nie i tak. Gdzie mogę teraz uzyskać nową kopię pliku datetime.x86_64-linux.gnu.so? :)
Joe

Odpowiedzi:

84

Zdarzyło mi się to po aktualizacji 14.10 i wydaje się, że /usr/bin/python2.7dzieje się tak, ponieważ moje środowiska wirtualne mają stare kopie tego - w przeciwieństwie do nowego datetimepliku binarnego - nie zawierają wbudowanego, a więc pojawia się błąd, gdy nie można go nigdzie znaleźć na dysku . Nowy interpreter wydaje się importować go bez żadnych operacji we / wy pliku (spróbuj uruchomić go pod, straceaby to sprawdzić).

Naprawiłem każde wirtualne środowisko, aktywując je i uruchamiając:

$ cp /usr/bin/python2.7 $(which python2.7)
Brandon Rhodes
źródło
5
Dzięki, ale dlaczego to konieczne? Złamanie Pythona podczas aktualizacji jest paskudne.
Samantha Atkins
1
Próbowałem innych odpowiedzi na tej stronie i one nie działały, ale ta zadziałała.
Michael Terry
2
Rozumiem, cp: '/usr/bin/python2.7' and '/usr/bin/python2.7' are the same fileale błąd nadal występuje
Umair,
@Umair W tym przypadku może być coś nie tak ze activateskryptem - zwykle po aktywacji which python2.7pokaże ścieżkę do środowiska Python, a nie zwróci ścieżkę do systemowego Python.
Brandon Rhodes
29

Możesz ponownie zainicjować virtualenv poprzez:

cd $VIRTUAL_ENV
virtualenv .
sureshvv
źródło
2
Zauważ, że powinno być virtualenv .zamiastvirtualenv ,
icyrock.com,
4
Ta odpowiedź wydaje się lepsza niż odpowiedź Brandona Rhodesa.
azurkin
Jeśli ktoś korzysta z virtualenvwrapper, może to zrobić cd $VIRTUAL_ENV.
maciek
OSError: [Errno 1] Operation not permitted
Cerin,
@Cerin, miałem ten sam problem, po prostu użyłem a, sudo virtualenv .aby zainstalować nowy plik wykonywalny Pythona, a następnie zmieniłem całość z powrotem $VIRTUAL_ENVna poprawnego właściciela katalogu.
iMitwe
2

Miałem ten sam problem i ostatecznie zdecydowałem, że musi to być interfejs AWS CLI, ponieważ zauważyłem, że ma on własny katalog python. Więc odinstalowałem interfejs AWS CLI i ponownie go zainstalowałem, co rozwiązało problem:

sudo pip uninstall awscli

sudo pip install awscli

JBaczuk
źródło
0

Jak znalazłem pewne zmiany w 14.04, więc musisz to zrobić z poziomu roota:

Tylko dla datetime:


ln -s /usr/lib/python2.7/lib-dynload/datetime.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/datetime.so

Dla wszystkich modułów:


ln -s /usr/lib/python2.7/lib-dynload/audioop.x86_64-linux-gnu.so                       /usr/lib/python2.7/lib-dynload/audioop.so
ln -s /usr/lib/python2.7/lib-dynload/_bsddb.x86_64-linux-gnu.so                        /usr/lib/python2.7/lib-dynload/_bsddb.so
ln -s /usr/lib/python2.7/lib-dynload/bz2.x86_64-linux-gnu.so                           /usr/lib/python2.7/lib-dynload/bz2.so
ln -s /usr/lib/python2.7/lib-dynload/_codecs_cn.x86_64-linux-gnu.so                    /usr/lib/python2.7/lib-dynload/_codecs_cn.so
ln -s /usr/lib/python2.7/lib-dynload/_codecs_hk.x86_64-linux-gnu.so                    /usr/lib/python2.7/lib-dynload/_codecs_hk.so
ln -s /usr/lib/python2.7/lib-dynload/_codecs_iso2022.x86_64-linux-gnu.so               /usr/lib/python2.7/lib-dynload/_codecs_iso2022.so
ln -s /usr/lib/python2.7/lib-dynload/_codecs_jp.x86_64-linux-gnu.so                    /usr/lib/python2.7/lib-dynload/_codecs_jp.so
ln -s /usr/lib/python2.7/lib-dynload/_codecs_kr.x86_64-linux-gnu.so                    /usr/lib/python2.7/lib-dynload/_codecs_kr.so
ln -s /usr/lib/python2.7/lib-dynload/_codecs_tw.x86_64-linux-gnu.so                    /usr/lib/python2.7/lib-dynload/_codecs_tw.so
ln -s /usr/lib/python2.7/lib-dynload/crypt.x86_64-linux-gnu.so                         /usr/lib/python2.7/lib-dynload/crypt.so
ln -s /usr/lib/python2.7/lib-dynload/_csv.x86_64-linux-gnu.so                          /usr/lib/python2.7/lib-dynload/_csv.so
ln -s /usr/lib/python2.7/lib-dynload/_ctypes_test.x86_64-linux-gnu.so                  /usr/lib/python2.7/lib-dynload/_ctypes_test.so
ln -s /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so                       /usr/lib/python2.7/lib-dynload/_ctypes.so
ln -s /usr/lib/python2.7/lib-dynload/_curses_panel.x86_64-linux-gnu.so                 /usr/lib/python2.7/lib-dynload/_curses_panel.so
ln -s /usr/lib/python2.7/lib-dynload/_curses.x86_64-linux-gnu.so                       /usr/lib/python2.7/lib-dynload/_curses.so
ln -s /usr/lib/python2.7/lib-dynload/datetime.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/datetime.so
ln -s /usr/lib/python2.7/lib-dynload/dbm.x86_64-linux-gnu.so                           /usr/lib/python2.7/lib-dynload/dbm.so
ln -s /usr/lib/python2.7/lib-dynload/_elementtree.x86_64-linux-gnu.so                  /usr/lib/python2.7/lib-dynload/_elementtree.so
ln -s /usr/lib/python2.7/lib-dynload/fpectl.x86_64-linux-gnu.so                        /usr/lib/python2.7/lib-dynload/fpectl.so
ln -s /usr/lib/python2.7/lib-dynload/future_builtins.x86_64-linux-gnu.so               /usr/lib/python2.7/lib-dynload/future_builtins.so
ln -s /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/_hashlib.so
ln -s /usr/lib/python2.7/lib-dynload/_hotshot.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/_hotshot.so
ln -s /usr/lib/python2.7/lib-dynload/_json.x86_64-linux-gnu.so                         /usr/lib/python2.7/lib-dynload/_json.so
ln -s /usr/lib/python2.7/lib-dynload/linuxaudiodev.x86_64-linux-gnu.so                 /usr/lib/python2.7/lib-dynload/linuxaudiodev.so
ln -s /usr/lib/python2.7/lib-dynload/_lsprof.x86_64-linux-gnu.so                       /usr/lib/python2.7/lib-dynload/_lsprof.so
ln -s /usr/lib/python2.7/lib-dynload/mmap.x86_64-linux-gnu.so                          /usr/lib/python2.7/lib-dynload/mmap.so
ln -s /usr/lib/python2.7/lib-dynload/_multibytecodec.x86_64-linux-gnu.so               /usr/lib/python2.7/lib-dynload/_multibytecodec.so
ln -s /usr/lib/python2.7/lib-dynload/_multiprocessing.x86_64-linux-gnu.so              /usr/lib/python2.7/lib-dynload/_multiprocessing.so
ln -s /usr/lib/python2.7/lib-dynload/nis.x86_64-linux-gnu.so                           /usr/lib/python2.7/lib-dynload/nis.so
ln -s /usr/lib/python2.7/lib-dynload/ossaudiodev.x86_64-linux-gnu.so                   /usr/lib/python2.7/lib-dynload/ossaudiodev.so
ln -s /usr/lib/python2.7/lib-dynload/parser.x86_64-linux-gnu.so                        /usr/lib/python2.7/lib-dynload/parser.so
ln -s /usr/lib/python2.7/lib-dynload/pyexpat.x86_64-linux-gnu.so                       /usr/lib/python2.7/lib-dynload/pyexpat.so
ln -s /usr/lib/python2.7/lib-dynload/readline.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/readline.so
ln -s /usr/lib/python2.7/lib-dynload/resource.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/resource.so
ln -s /usr/lib/python2.7/lib-dynload/_sqlite3.x86_64-linux-gnu.so                      /usr/lib/python2.7/lib-dynload/_sqlite3.so
ln -s /usr/lib/python2.7/lib-dynload/_ssl.x86_64-linux-gnu.so                          /usr/lib/python2.7/lib-dynload/_ssl.so
ln -s /usr/lib/python2.7/lib-dynload/termios.x86_64-linux-gnu.so                       /usr/lib/python2.7/lib-dynload/termios.so
ln -s /usr/lib/python2.7/lib-dynload/_testcapi.x86_64-linux-gnu.so                     /usr/lib/python2.7/lib-dynload/_testcapi.so

Również jeśli używasz wirtualnej kopii env

cp $(which python2.7) /opt/graphite/bin/python

do twojego środowiska

Ilya Shevyrev
źródło
3
Uaktualniłem do 14.04 i nie musiałem robić żadnego dowiązania symbolicznego. Czy możesz podać jakieś dowody, że bałaganie się bibliotek systemowych w ten sposób jest konieczne i nie można go uniknąć?
Andrea Lazzarotto,
0

Wystąpił błąd podczas aktualizacji z Ubuntu 14.04 do 14.10. Odtworzyłem mój virtualenv i problem zniknął. Więc jeśli pracujesz z virtualenv, powinieneś go ponownie utworzyć.

Jeśli jednak tego nie zrobisz, przypuszczam, że ponowna instalacja projektu będzie działać. Nie dotykaj żadnych bibliotek systemowych! Może na razie działać, ale potencjalnie może prowadzić do problemów z innymi.

Dzień Sądu Ostatecznego
źródło
0

Dzieje się tak po niektórych aktualizacjach Ubuntu. Moje ulubione rozwiązanie to

$ virtualenv --no-site-packages path/to/virtualenv/dir

To aktualizuje wszystko, co potrzebne, bez usuwania już zainstalowanych pakietów.

Jeśli masz wiele wirtualnych aktualizacji, możesz użyć xargs:

$ ls ~/directory/with/virtualenvs | xargs -L1 virtualenv --no-site-packages
brandizzi
źródło