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

Question

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

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

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

Таким образом, физический путь <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-compressor. Оказывается, он напрямую передается из оболочки. Который заставил меня удалить все переменные и буквально просто попытался получить компилятор lessc для анализа файла.

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

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

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

UPDATE (02/08/2012)

Если бы полный «ДУХ» момент, когда я, наконец, толкнул мой код на промежуточной среды и побежал collectstatic. Путь @import, который я использовал, работал отлично в разработке, потому что это был физический путь к файлу , затем, но однажды collectstatic выполнил все, все перемещено и относительно <project_root>/static/.

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

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

Answer 2

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

Насколько я могу судить по экспериментам, 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" 

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

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

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

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