Каким должен быть мой путь LESS @import?

Question

Вот сценарий:

Я использую Django 1.3.1, использующий статические файлы и django-compress (последняя стабильная версия) для компиляции файлов LESS.

У меня есть каталог "assets", который подключен к статическим файлам с помощью STATICFILES_DIRS (для статических ресурсов для всего проекта). В этом каталоге у меня есть каталог "css", и в этом файле "lib.less", который содержит LESS-переменные и миксины.

Итак, физический путь - <project_root>/assets/css/lib.less, и он обслуживается в /static/css/lib.less.

В одном из статических каталогов моих приложений у меня есть другой файл LESS, который необходимо импортировать вышеупомянутым. Физический путь для этого - <project_root>/myapp/static/myapp/css/file.less, и он будет обслуживаться в /static/myapp/css/file.less.

Моя первая мысль была:

@import "../../css/lib.less"

(т. Е. На основе URL-адреса перейдите на уровень от /static/myapp/css до /static/, затем пройдите вниз до /static/css/lib.less).

Тем не менее, это не работает, и я попробовал практически каждую комбинацию URL-адресов и физических путей, которые я могу придумать, и все они дают мне FilterError s в шаблоне из-за невозможности найти файл для импорта.

У кого-нибудь есть идеи, каким должен быть фактический путь импорта?

Answer 1

После отслеживания точно, откуда произошла ошибка в источнике django-компрессора. Оказывается, прямо передается от оболочки. Это подтолкнуло меня к удалению всех переменных и буквально к попытке получить компилятор lessc для анализа файла.

Оказывается, он хочет, чтобы относительный путь от исходного файла к файлу был импортирован в терминах физического пути к файловой системе. Таким образом, я должен был вернуться обратно к своему <project_root>, а затем сослаться на assets/css/lib.less. Фактический импорт, который в итоге сработал, был:

@import "../../../../assets/css/lib.less"

Что очень странно, так это то, что lessc не принимает абсолютный путь к файловой системе (т.е. /path/to/project/assets/css/lib.less). Я не уверен почему.

ОБНОВЛЕНИЕ (02/08/2012)

Был полный "DUH" момент, когда я, наконец, отправил свой код в свою промежуточную среду и запустил collectstatic. Путь @import, который я использовал, отлично работал при разработке, потому что это был физический путь к файлу , затем , но как только collectstatic сделал свое дело, все перемещается и относительно <project_root>/static/.

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

ТАК ... Я сломал и переместил все файлы LESS вместе под <project_root>/assets/css/, и рационализировал перемещение файлов LESS из приложений, потому что, поскольку они привязаны к файлу уровня проекта, чтобы функционировать, они Самостоятельно проектируешь себя.

Answer 2

Я вроде как в той же привязке, и это то, что я придумал для самых последних версий компрессоров и lessc для интеграции со статическими файлами.Надеюсь, это поможет некоторым другим людям

Насколько я могу судить из экспериментов, lessc не имеет понятия об абсолютных или относительных путях.Скорее, он поддерживает путь поиска, который включает в себя текущий каталог, каталог, содержащий файл меньшего размера, и все, что вы передаете ему через --include-path

, поэтому в моей конфигурации для компрессора я поместил

COMPRESS_PRECOMPILERS = (
    ('text/less', 'lessc --include-path=%s {infile} {outfile}' % STATIC_ROOT),
)

Скажем, после запуска collectstatic У меня есть начальная загрузка, живущая по

STATIC_ROOT/bootstrap/3.2.0/bootstrap.css. 

Тогда из любого меньшего файла я теперь могу написать

@import (less, reference) "/bootstrap/3.2.0/bootstrap.css"

, что позволяет мнеиспользовать классы начальной загрузки как меньшее количество миксинов в любом из моих файлов поменьше!

Каждый раз, когда я обновляю файл меньшего размера, я должен запускать collectstatic для агрегирования их в локальном каталоге, чтобы компрессор мог дать lessправильные исходные файлы для работы.В противном случае компрессор справится со всем без проблем.Вы также можете использовать collectstatic -l для символической ссылки, что означает, что вам нужно собирать файлы только при добавлении нового.

Я рассматриваю реализацию команды управления для сглаживания процесса разработки, который подклассов runserver для вызова collectstatic каждый раз, когда сервер перезагружается, или используется django.utils.autoreload для прямого вызова collectstatic при обновлении.

Редактировать (2014/12/01): мой подход, как описано вышетребуется локальный статический корень.В своей производственной среде я использовал удаленное хранилище с автономным сжатием, поэтому для развертывания требуется пара дополнительных шагов.В дополнение к вызову collectstatic для синхронизации статических файлов с удаленным хранилищем я вызываю collectstatic с другим файлом конфигурации django, который использует локальное хранилище.После того, как я собрал файлы локально, я могу вызвать «компресс», настроив его для загрузки файлов результатов в удаленное хранилище, но в локальном хранилище ищите исходные файлы.