Fabric: Разделить не зависящие от ssh функции в отдельную библиотеку

:торт:

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

Обновлено описание куча.

@kennethreitz : это действительно была бы новая «вещь», просто основанная на существующих потребностях / наборе функций этой половины Fabric. Идея состоит в том, чтобы это была отдельная сущность, связанная с установкой, графиком разработки и т. д., но по-прежнему контролируемая разработчиками/сообществом Fabric.

Идеи:

• Тони - как в Тони Мастерс, также известном как Надсмотрщик (комиксы~)
• Генеральный директор - управляет делами (или царь или что-то подобное в этом роде)

Извините, я лажу с именами :(

Также такие вещи, как «кирк» (как в слове «капитан кирк»).

Я пытался придумать что-то связанное с тканью, связанное с выполнением задач, но я не могу придумать ничего, что связано с задачами + тканью.

Но Loom тоже неплохое имя, я не думаю.

Мозговой штурм по первоначальному имени.

Концепции

• Бег/бег трусцой/и т.д.
• Исполнение (приказов, людей, возможно, хотя это немного мрачно и т. д.)
• Задачи (например, дела, поручения и т. д.)
• Может быть , некоторые из отвергнутых или похожих названий из #461, поскольку идея ткачества или сборки вещей из ткани также относится к задачам.

Имена, не используемые в PyPI

• runner
• executor
• go
  
  
  
  • Путаница с языком программирования и/или настольной игрой, особенно если у первого есть двоичный файл, специально называемый go
  
  
  • К лучшему или к худшему, есть много потенциально глупых названий задач, таких как away или fuck_yourself или bother_somebody_else
  
  
• weaver

Двоичные имена

Спасибо, Оксфордский тезаурус американского писателя, представленный приложением OS X Dictionary!

• run
• execute
• go
  
  
  
  • См. выше
  
  
• create (например, make )
• fabricate (слишком длинно, слишком легко спутать с fab )
• fab (т. е. назвать эту новую библиотеку по-другому, но по-прежнему устанавливать двоичный файл fab ; если оба присутствуют в системе, то Fabric имеет приоритет? Кажется глупой идеей.)
• generate
• produce
• fashion (мех)
• build
• devise
• shape
• setup
• weave

Сегодня не в лучшей форме для мозгового штурма. Хотите моар.

@dstufft Loom - нормальное имя, а CEO - в основном нормальная концепция (не большой поклонник ссылки на комикс, хотя бы потому, что она кажется неясной, я никогда не слышал об этом персонаже ;)). Основная проблема заключается в том, чтобы придумать хорошее бинарное имя, я чувствую, что глагол в значительной степени необходим для того, чтобы он работал хорошо. Не уверен, что сработает для любого из них.

Босс: Управляет делами.

принять участие Вроде как Make, но для Python.

Должностное лицо.

Мне нравится идея ориентироваться вокруг задач. Хм..

@kennethreitz Мне нравится Босс, за исключением потенциальной путаницы с одним уроженцем Нью-Джерси (извините, просто не фанат, неудачный опыт соседа по комнате в колледже)

Как я уже сказал @dstufft , бинарные имена здесь определенно являются ключевыми, поэтому, если можете, постарайтесь не забывать и о них. Отличное название проекта не поможет, если название проекта-как-бинарный звучит глупо;)

Горничная интересная. Выполняет ваши задачи за вас. Чем-то похожие на «Сделать».

Батлер тоже. Мы могли бы выбрать случайное имя дворецкого, звучащее по-британски.

maid clean , maid release , maid test . Мне это нравится.

Если не считать посягательства на мою (безграничную, естественно) мужественность, maid довольно хорош, хотя и не соответствует шаблону глагола. (То есть это одно из лучших двоичных имен без глагола.) (EDIT: а что делают дворецкие _do_? Butle?)

На всякий случай я просто присел на имя. Пока мне это очень нравится.

Boss в качестве имени библиотеки уже занят FWIW

Во вторник, 21 февраля 2012 г., в 20:38 Джефф Форсиер написал:

Если не считать посягательства на мою (безграничную, естественно) мужественность, maid довольно хорош, хотя и не соответствует шаблону глагола. (То есть это одно из лучших не глагольных бинарных имен.)

---

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/fabric/fabric/issues/565#issuecomment-4095609

intern — тоже невероятно крутой выбор.

@dstufft Так оно и есть, и я тоже не мог придумать для этого подходящего двоичного имени, boss docs не совсем подходит.

@kennethreitz упомянул bake в IRC, что действительно соответствует теме make/rake, а также подходит как глагол вызова (например, $ bake docs , хотя тематически это немного не так, похоже, что это так) d лучше подходит для Chef или что-то в этом роде.

РЕДАКТИРОВАТЬ: также deliver . Моя первоначальная реакция на этот проект была несколько положительной ( $ deliver build $ deliver docs ), но нет _отличного_ названия проекта, которое не было бы слишком глупым и немного длинным.

$ invoke taskname (названия проектов: invoker , invoked , ???)

Вызвано.

Мне очень нравятся Invoked и invoke docs invoke tests invoke publish и т.д.

Имя проекта может быть просто «Invoke», нужны ли двоичному файлу и проекту разные имена?

Я думаю, что «вызванный» имеет немного больше стиля, чем «вызвать», но любой из них может работать.

Имя не обязательно должно отличаться, нет, просто во много раз оно имеет больше смысла.

Пока я шел к поезду (сейчас в указанном поезде: P, вперед, привязывайте смартфон!), у меня возникла мысль, что мы _можем_ пропустить все это и просто переместить всю сторону fab + fabfile.py вещей в эту «новую» библиотеку (и назовите ее, скажем, fabricator ).

Другими словами, наличие одного вызываемого для автономной библиотеки и другого для установки с использованием SSH не обязательно должно происходить и даже может быть во вред.

Плюсы:

• Нет необходимости в новом двоичном имени
• Наличие двух бинарных имен в любом случае сбивает с толку.
• Если бы новая библиотека _не_ использовала "fabfiles", у нас также было бы два разных типа "файлов задач", опять же запутанные/дополнительный код/и т.д.

Минусы:

• Возможна путаница между двумя проектами из-за похожих названий.
• Новый проект должен быть дополнительно расширяемым, чтобы позволить всем Fabric-isms (например, почти всем флагам CLI и т. д.) продолжать работать как есть.
  
  
  
  • Т.е. pip install fabricator дает нам fab , у которого будет небольшой набор флагов
  
  
  • Затем, если вы pip install fabric , вдруг тот же fab должен выставить все дополнительные флаги CLI Fabric, если не другие вещи тоже
  
  
  • OTOH, это не то же самое, что позволить «клиентскому» коду расширять синтаксический анализ CLI - это _плохо_, это просто дополнительная работа, которую нужно выполнить заранее.
  
  

Вы можете сделать клиент командной строки расширяемым. Посмотрите, как нос позволяет выражать точки входа плагина из своего инструмента командной строки.

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

Я думаю, что путаница в именах будет проблемой.

Это личное дело, но мне нравится внешний вид invoke test invoke docs больше, чем fab test .

Что касается различных двоичных файлов, я бы просто удостоверился, что основной двоичный файл (invoke) является расширяемым, чтобы позволить происходить всем вещам структуры, а затем fab просто вызывает ту же точку входа, что и вызов (т.е. фактические двоичные файлы fab/invoke были бы просто ультраминималистичными абонентами main() (или чего-то еще).

Я думаю, если вы пойдете по маршруту Invoke + Fabric, что до 2.0, как fabfiles, так и «Invokefiles»? будет поддерживаться, а то с 2.0 только Invoke files?

Так что, по сути, я +1 за то, что разделил его на отдельные «исполнители задач» и «удаленные / ssh-материалы», вставил прокладки совместимости для 1.x и отказался от поддержки 2.x. Я думаю, что это разделение сделало бы обе библиотеки лучше, средство запуска задач поддерживало бы действительно хорошую расширяемость (и, возможно, внешние задачи, от которых можно легко зависеть, запускать и т. д.). И удаленный/ssh материал выиграет от меньшего набора обязанностей, что позволит ему быть более сфокусированным/

Мои центы в любом случае.

Я должен уточнить, что я не ненавижу другой путь, я рад, что эта дискуссия вообще происходит :)

@dstufft Большое спасибо за мысли, я почти со всем согласен. Вы правы в том, что бинарные файлы просто заглушки, вот как сейчас работает Fabric, я беспокоюсь исключительно о поведении и путанице пользователей.

@dcolish Я не имел в виду, что расширение CLI невозможно, и нос определенно является хорошим прототипом для изучения.

Если мы выберем «вызов», может быть, имя файла может быть invocations(.py) ? Прикосновение к глупости/тематическому парку, но оно подходит грамматически, и invokefile.py кажется мне немного неловким. Или, возможно, пойти по пути соглашения Rake и просто использовать tasks(.py) .

Частично связанный с этим, я думаю, что мы также должны определенно сосредоточиться на аспекте модуля/папки в будущем. Так как это Just Python, он по-прежнему будет поддерживаться, но с точки зрения учебных материалов и документов, использование invocations/__init__.py по умолчанию может быть хорошим решением.

Мне нравится tasks.py . invocations.py странно печатать.

Ну, не то чтобы вам приходилось печатать это очень часто, а? ;) Но да, tasks/ или tasks.py более глобально очевидны.

файл_задачи.py

вы invoke tasks(.py|/), формулировка в любом случае хороша :)

Да, установка «это tasks , которую вы invoke » работает очень хорошо с точки зрения привязки ключевых слов к английским описаниям того, как это работает. Сразу видно, без излишеств, без зазнайства и т.д.

@kennethreitz Я никогда не был большим поклонником XYZFile как соглашения об именах, и особенно с учетом того, что в наши дни это часто _не_ один файл, я не вижу необходимости продолжать соглашение за пределами Fab 1.x :)

Я бы очень хотел, чтобы это произошло. Я всегда рассматривал Fabric как универсальный способ Pythonic для хранения «задач» для проекта, независимо от того, являются ли они локальными или удаленными, что-то более близкое к Rake/Make. Однако, пытаясь представить новых людей, некоторые люди были сбиты с толку этой точкой зрения и рассматривали ее только как инструмент развертывания.

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

@askedrelic Да, к сожалению, наличие двух вещей в одном всегда немного сбивало с толку.

Не по теме: я вызываю @tswicegood в эту ветку, так как мы с ним обсуждали этот вопрос несколько недель назад, и я полагаю, что он, возможно, захочет высказаться. Как обычно, я оставляю за собой право не согласиться;)

Меня вызвали? :-)

Мне нравится идея перехода к tasks в качестве модуля, а не к fabfile . Логичнее и короче. Я, например, ненавижу устанавливать полный стек dep только для того, чтобы иметь возможность запускать fab test внутри Armstrong, так что все, что можно сделать, чтобы извлечь это, у меня большой плюс.

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

if __name__ == "__main__":
    <some_mod>.main()

Тогда вы просто используете Python. Я в порядке с исполняемым файлом, просто не знаю, нужен ли он.

FWIW, несколько недель назад я начал проект по обработке создания пакетов под названием flunky . Придерживаясь этой сопутствующей темы, доступны footman или lacky (последний конфликтует с lackie -- проектом Ruby). Другой будет пятницей, как в пятнице девушки/мужчины . Он проходит тест GitHub/PyPI/Homebrew в том смысле, что ничего не называется. На самом деле, теперь, когда я думаю об этом, это был бы мой первый выбор.

Кстати, интересно, сколько времени пройдет, пока @niran не представит PR, обновляющий README, чтобы включить очевидную, хотя и ужасную музыкальную тему.

Я думаю, что иметь "двоичный файл" на вашем- $PATH (особенно учитывая, что в настоящее время это _не_ настоящий двоичный файл, а просто созданная setuptools заглушка, которая вызывает (invoked|fabric).main() ) является наиболее удобным для пользователя. , и я не вижу никаких преимуществ в перемещении содержимого этой заглушки для автоматической генерации внутри модуля задач (и на самом деле вижу в этом ряд недостатков).

И да, весь смысл этого в том, чтобы в конечном итоге получить библиотеку, которая позволяет вам получать сложные вещи без каких-либо SSH/сетевых/крипто-отложений :)

Я полностью согласен с @bitprophet в отношении исполняемого файла. Это значительно облегчает бег. Если кто-то хочет использовать что-то кроме invoke / fab в своем личном проекте, это просто заглушка, поэтому вы можете легко создать свой собственный двоичный файл (и он может легко жить в finalname.__main__.main , и в этом случае вы также можете просто python -m finalname , если хотите.

+1.

Просто подкинуть идею, я тоже думаю, что это удобнее. FWIW, я зарегистрировался в пятницу на PyPI, если вы хотите его использовать.

@bitprophet Извините, я подумал, что вы знаете, как использовать точки входа. Я голосовал, по-своему, за то, чтобы сделать внешний интерфейс в стиле носа и оставить имя потрясающим.

Идеи отличные, я люблю идеи :)

Пятница слишком жеманна, хотя мне нравится отсылка к поп-культуре. Песня такая классная! :Тролль:

Я думаю, что на данный момент я собираюсь использовать invoke как имя пакета/проекта и двоичного файла. Йоинк! Invoker или Invoked были другими возможностями для первого (то есть все еще с двоичным файлом invoke ), но я не мог придумать ни одной веской причины, чтобы не пойти прямым путем.

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

@dcolish Принято , спасибо!

Я еще не принял окончательного решения, но я думаю, что на данный момент разумный подход таков:

• Invoke — это отдельная вещь, собственная новая личность/"бренд", использует двоичный файл invoke , ищет модуль tasks и т. д.
  
  
  
  • Это чисто, просто концептуально для пользователей, использующих только Invoke, а не Fabric, удаляет исторический багаж и т. д.
  
  
• Invoke предоставляет любой общий код, который Fabric (или другие инструменты) может захотеть использовать, как общедоступные API.
• Fabric продолжает использовать fab и искать модуль fabfile , добавляя зависимость времени установки от Invoke и используя API-интерфейсы Invoke для вызова этого общего кода.
  
  
  
  • Это означает, что установка Fabric приводит к созданию двух двоичных файлов, но с точки зрения пользователей, сосредоточенных на Fabric, им не нужно _знать_, что invoke / tasks существуют/являются вариантами, потому что они d никогда не использовать их - fab по-прежнему является расширенным набором функций.
  
  
  • Камнем преткновения являются пользователи, которые хотят использовать как Invoke (например, в других проектах, не имеющих Fabfiles), так и Fabric, в отношении того, как invoke и fabric связаны друг с другом и ведут себя . Эти люди могут быть заинтересованы в том, чтобы invoke и fab были простыми псевдонимами друг друга (например, установка Fabric меняет поведение invoke , например, как работают плагины Nose).
  
  
  • Тем не менее, я думаю, что лучше, чтобы они вели себя по-разному — fab _должны_ различаться _по крайней мере_ в "какое имя модуля задачи мне искать?" смысле, и в этот момент мы можем также иметь его собственным созданием, а связь между Fabric и Invoke заключается только в том, как Fabric использует кодовую базу Invoke.
  
  

РЕДАКТИРОВАТЬ: я должен быстро взглянуть на то, _как_ это будет работать, прежде чем делать что-либо окончательное. Практика против теории и все такое. Может столкнуться с углами, о которых я здесь не думаю.

У Invoke сейчас есть бета-версия (после большой недавней работы по ее созданию). Уже в:

• Лучшее, более явное, но все еще почти нулевое пространство имен
• «Настоящий» анализатор флагов CLI, не более foo:bar,lol , включая автоматический перевод функции argspec в спецификацию CLI
• Попытка спроектировать биты выполнения задачи, чтобы они были расширяемыми/переопределяемыми в отношении распараллеливания.
• Что было сделано для поддержки: предварительных задач (укажите задачи, которые должны выполняться перед другими задачами)
• Средство запуска локальных задач с возможностью захвата и печати run (хотя, вероятно, не работает в Windows)
• Может, забыл еще пару битов?

Спринт на нем и надежда начать прототипирование того, как Fab 2 будет крепиться к нему, на этой неделе.

обеспечить чистоту
обеспечить построенный
"обеспечить" "государство"

Каково состояние ткани 2? Есть ли вилка, которая покрывает это? Я имею в виду материал, который должен покрывать Fabric2, который не вызывается.

@mvaled Вскоре он появится в частной «чистой» ветке репозитория ткани.

Извините, если не по теме, но я как бы должен спросить еще раз:
Где я могу найти ткань 2?
Мне действительно нравится Invoke, и это кажется огромным улучшением, но чего не хватает в версии Invoke 1.0? (описана как основа для ткани 2)

Спасибо за отличную работу над Invoke и Fabric!

@dmr Я нахожусь в процессе создания Fabric 2, работающего поверх Invoke. Ряд функций, которые будут перенесены из Fabric 1, повлияют на проектные решения для Invoke (для новых функций или существующих — например, недавняя переработка конфигурации была одной из них), поэтому я не хочу маркировать Invoke 1.0, пока она не будет « "проверено в бою" достаточно.

Мой план состоит в том, чтобы альфа-версия Fabric 2 была готова для публики на PyCon самое позднее (в идеале намного раньше), и это приведет к Fabric 2.0 + Invoke 1.0.

Спасибо за разъяснения, чем могу помочь?

Я работаю над этим в частной ветке в течение короткого времени, пока не получу что-то, чем я буду доволен, и объявлю об этом в твиттере/списке рассылки/и т. д., как только я буду готов для обратной связи, поэтому, пожалуйста, следите за обновлениями.

Я начал переключаться на вызов в сочетании с командами оболочки и некоторыми Paramiko, потому что ткань — последний пакет без поддержки python3 в моем проекте.

Есть ли ETA для Fabric 2.0 и Invoke 1.0, поскольку Python 3.5 был выпущен вчера и будет использоваться по умолчанию в Ubuntu 16.04 LTS?