2009-10-15 4 views
2

Какой самый короткий способ импортировать модуль из удаленного, относительного каталога?Импорт модулей Python из удаленного каталога

Мы использовали этот код, который не так уж плох, за исключением вашего текущего рабочего каталога имеет, чтобы он был таким же, как в каталоге, где этот код или относительные разрывы пути, которые могут быть подвержены ошибкам и запутывать пользователей ,

import sys 
sys.path.append('../../../Path/To/Shared/Code') 

Этот код (я думаю) исправляет эту проблему, но гораздо больше подходит для ввода.

import os,sys 
sys.path.append(os.path.realpath(os.path.join(os.path.dirname(__file__), '../../../Path/To/Shared/Code'))) 

Есть ли более короткий способ добавления абсолютного пути? Краткость имеет значение, потому что это должно быть напечатано/появилось во многих наших файлах. (Мы не можем это исключить, потому что тогда это было бы в общем коде, и мы не смогли бы добраться до него. Курица & яйцо, самозарядка и т. Д.)

Плюс это беспокоит меня, что мы слепо добавляем в sys .path, но это будет еще больше кода. Я уверен, что что-то в стандартной библиотеке могло бы помочь в этом.

Это обычно появляется в файлах сценариев, которые запускаются из командной строки. Мы запускаем Python 2.6.2.

Edit: Причина мы используем относительные пути, что мы, как правило, имеют несколько независимых копий кодовую на наших компьютерах. Важно, чтобы каждая копия кодовой базы использовала собственную копию общего кода. Поэтому любое решение, которое поддерживает только одну базу кода (например, «Поместить его в пакеты сайта»), не будет работать для нас.

Любые предложения? Спасибо!

ответ

2

Вы объяснили в комментариях, почему вы не хотите, чтобы установить «единый каталог сайтов-пакеты», но как насчет сдачи в site-packages один, крошечном модуля, скажет jebootstrap.py:

import os, sys 

def relative_dir(apath): 
    return os.path.realpath(
     os.path.join(os.path.dirname(apath), 
     '../../../Path/To/Shared/Code')) 

def addpack(apath): 
    relative = relative_dir(apath) 
    if relative not in sys.path: 
    sys.path.append(relative) 

Теперь везде в вашем коде вы можете просто

import jebootstrap 
jebootsrap.addpack(__file__) 

и всю остальную часть вашего общего кодовую может оставаться independen t за установку.

+0

Он не устраняет требования, что рабочий каталог должен быть конкретным, хотя ... Хотя это не кажется большой проблемой. Но я должен сказать, что эта ситуация просто кричит buildout/virtualenv мне. –

+0

@ Lennart, у меня была глупая опечатка, не использующая аргумент 'apath' в' relative_dir' - исправлена ​​это сейчас, и вы увидите, что нет никакого требования, чтобы рабочий каталог был чем-то особенным - передан '__file__' to 'addpack' - это то, где живет вызывающий модуль, нечего делать с текущим рабочим каталогом. Конечно, возможны и расширенные подходы, такие как «virtualenv», но это не столько о _development_, сколько о нескольких отключенных _deployments_ (на той же машине без разработки), если я правильно прочитал вопрос. –

+0

Ну, я должен сказать, что я считаю, что использование virtualenv проще, чем это, так что продвинутый - это вопрос вкуса, я думаю. ;) Я не вижу причин не использовать virtualenv или buildout для развертываний. Напротив, развертывания - это то, что сделано для создания. –

1

По какой-либо причине вы не хотели бы создавать собственный собственный кодовый каталог под пакетами сайтов? Затем вы можете просто импортировать импорт shared.code.module ...

+0

возможно символическая ссылка? –

+0

Нам не нравятся сайты-сайты, потому что у нас обычно есть несколько независимых копий кодовой базы на наших компьютерах. Мы хотели бы, чтобы каждая копия кода использовала свою копию общего кода (следовательно, относительный путь). Все это разбивается на один каталог сайтов-пакетов. –

-1

У вас есть несколько способов обработки импорта, все они задокументированы в руководстве по языку Python.

См http://docs.python.org/library/site.html и http://docs.python.org/reference/simple_stmts.html#the-import-statement

  1. Положите его в сайт-пакетов и иметь несколько установок Python. Вы выбираете установку с использованием обычной переменной окружения PATH.

  2. Поместите каталог в переменную среды PYTHONPATH. Это настройка для каждого человека, поэтому вы можете управлять несколькими версиями кодовой базы таким образом.

  3. Поместите каталог в .pth файлов в свои пакеты сайта. Вы выбираете установку с использованием обычной переменной окружения PATH.

+0

Я думаю, что все эти решения ломаются, если на машине имеется более одной копии кода (включая общий код). (То же самое я прокомментировал в Crad.) Я отредактировал свой вопрос, чтобы объяснить этот момент. –

+0

@Jon Eric: Если вы используете 'PYTHONPATH', у каждого человека есть свои личные ссылки на их выбранную версию кодовой базы. –

+0

Это одна установка на человека или несколько человек? У меня было ощущение, что было много копий, не обязательно много людей. –

4

Поскольку вы не хотите устанавливать его в сайт-пакеты, вы должны использовать buildout или virtualenv для создания изолированной среды разработки. Это решает проблему и означает, что вам больше не нужно возиться с sys.path (на самом деле, потому что Buildout делает именно это для вас).

Смежные вопросы