Fabric: ssh에 의존하지 않는 기능을 별도의 라이브러리로 분할

:케이크:

물론 사용 사례에 잘 맞는 완전히 새로운 도구도 항상 선택 사항입니다.

설명을 업데이트했습니다.

@kennethreitz : 이것은 Fabric의 절반에 대한 기존 요구/기능 세트를 기반으로 하는 새로운 "물건"이 될 것입니다. 아이디어는 설치, 개발 일정 등 자체 엔터티이지만 여전히 Fabric 개발자/커뮤니티에 의해 제어되는 것입니다.

아이디어:

• Tony - Tony Masters 일명 Taskmaster(만화책~)
• CEO - 일을 실행합니다(또는 czar 또는 이와 유사한 것).

죄송합니다 이름이 빠릅니다 :(

또한 "kirk"와 같은 것(캡틴 커크에서와 같이).

나는 작업 실행과 관련된 패브릭과 관련된 것을 생각하려고했지만 작업 + 패브릭과 관련이있는 것은 생각할 수 없습니다.

하지만 Loom도 나쁘지 않은 이름이라고 생각합니다.

이니셜 이름 브레인스토밍.

개념

• 달리기/조깅 등
• 실행 (명령, 사람들은 아마도 그것이 약간 섬뜩하지만 등)
• 할 일(할 일, 심부름 등)
• 직물에서 물건을 짜거나 조합하는 아이디어가 작업에 적용되는 한 # 461 에서 거부되거나 유사한 이름 중 일부가 있을 수 있습니다.

PyPI에서 사용되지 않는 이름

• runner
• executor
• go
  
  
  
  • 프로그래밍 언어 및/또는 보드 게임과의 혼동, 특히 전자에 go 라는 바이너리가 있는 경우
  
  
  • 좋든 나쁘든 away 또는 fuck_yourself 또는 bother_somebody_else 와 같은 어리석은 작업 이름이 많을 수 있습니다.
  
  
• weaver

바이너리 이름

감사합니다. OS X의 사전 응용 프로그램이 제공하는 Oxford American Writer's thesaurus!

• 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 에게 말했듯이 바이너리 이름은 확실히 여기에서 중요하므로 가능하면 이 이름도 염두에 두십시오. project-name-as-binary가 다소 멍청하게 들리면 훌륭한 프로젝트 이름은 도움이 되지 않습니다. ;)

하녀 는 흥미 롭습니다. 당신을 위해 당신의 작업을 수행합니다. "메이크"와 유사합니다.

집사 도. 우리는 무작위로 영국식으로 들리는 집사 이름을 선택할 수 있습니다.

maid clean , maid release , maid test . 좋아요.

내 (무한한, 자연스럽게) 남성성에 영향을 미치는 것 외에, maid 는 비록 그것이 동사 패턴에 맞지 않더라도 꽤 좋습니다. (즉, 더 나은 비동사 이진법 이름 중 하나입니다.) (편집: 집사는 무엇을 _do_합니까? Butle?)

만일을 대비해서 이름을 쪼그리고 앉았습니다. 나는 그것을 지금까지 많이 좋아한다.

Boss는 라이브러리 이름으로 이미 FWIW를 사용하고 있습니다.

2012년 2월 21일 화요일 오후 8시 38분에 Jeff Forcier는 다음과 같이 썼습니다.

내 (무한한, 자연스럽게) 남성성에 영향을 미치는 것 외에, maid 는 비록 그것이 동사 패턴에 맞지 않더라도 꽤 좋습니다. (즉, 더 나은 비동사 바이너리 이름 중 하나입니다.)

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern 또한 매우 훌륭한 선택입니다.

@dstufft 그래서, 그리고 그것에 대한 좋은 바이너리 이름을 생각할 수 없었습니다. boss docs 는 잘 맞지 않습니다.

@kennethreitz 는 IRC에서 bake 를 언급했는데, 이는 make/rake 테마에 적합하고 호출 동사로도 적합합니다(예: $ bake docs , 주제적으로는 약간 다르지만 느낌이 ' d Chef나 뭔가에 더 잘 맞습니다.

편집: 또한 deliver . 이것에 대한 나의 초기 반응은 다소 긍정적이었습니다( $ deliver build $ deliver docs ). 그러나 너무 어리석지 않은 _훌륭한_ 프로젝트 이름이 없으며 조금 깁니다.

$ invoke taskname (프로젝트 이름: invoker , invoked , ???)

호출됨.

Invoked 및 invoke docs invoke tests invoke publish 등을 정말 좋아합니다.

프로젝트 이름도 "Invoke"일 수 있습니다. 바이너리와 프로젝트에 다른 이름이 필요합니까?

나는 'invoked'가 'invoke'보다 조금 더 피자를 가지고 있다고 생각하지만 둘 중 하나가 작동할 수 있습니다.

이름은 다를 필요가 없습니다. 아니, 몇 번이나 더 의미가 있습니다.

나는 기차로 걸어가는 동안 (지금 기차에서 :P go go 스마트폰 테더링!) 하는 생각을 했습니다. 그것은 우리가 이 모든 것을 건너뛰고 단순히 fab + fabfile.py 전체를 이동할 수 있다는 것입니다. 이 "새로운" 라이브러리에 대한 것입니다(그리고 fabricator 라고 부릅니다).

즉, 독립 실행형 lib에 대해 하나의 호출 가능 항목을 갖고 SSH 사용 설정에 대해 다른 호출 가능 항목을 갖는 것이 반드시 발생해야 하는 것은 아니며 손해가 될 수도 있습니다.

플러스:

• 새로운 바이너리 이름 필요 없음
• 어쨌든 두 개의 바이너리 이름이 있으면 혼란스러울 것입니다.
• 새 lib가 "fabfiles"를 사용하지 _않으면_ 두 가지 다른 "작업 파일" 유형도 갖게 됩니다. 다시 혼동/추가 코드/기타

빼기:

• 유사한 이름으로 인한 두 프로젝트 간의 잠재적인 혼동
• 새 프로젝트는 모든 Fabric-isms(예: 거의 모든 CLI 플래그 등)가 있는 그대로 계속 작동할 수 있도록 추가 확장 가능해야 합니다.
  
  
  
  • 예를 들어 pip install fabricator 는 우리에게 fab 를 제공합니다. 여기에는 작은 플래그 세트가 있습니다.
  
  
  • 그런 다음 pip install fabric 하면 갑자기 동일한 fab 가 다른 모든 추가 Fabric CLI 플래그를 표시해야 합니다.
  
  
  • OTOH "클라이언트" 코드가 CLI 구문 분석을 확장하도록 허용하는 것은 _나쁜_ 일이며, 미리 수행해야 하는 더 많은 작업일 뿐입니다.
  
  

명령줄 클라이언트를 확장할 수 있습니다. 코가 어떻게 플러그인 진입점을 명령줄 도구에서 표현할 수 있는지 살펴보세요.

추가 확장성은 어떤 방향으로 가더라도 좋을 것이라고 생각합니다.

이름 혼동이 문제라고 생각합니다.

이것은 개인적인 일이지만 fab test invoke test invoke docs 의 모양이 더 좋습니다.

다른 바이너리가 진행되는 한, 핵심 바이너리(호출)가 모든 패브릭 작업을 수행할 수 있도록 확장 가능한지 확인한 다음 fab에서 invoke와 동일한 진입점을 호출하도록 합니다(즉, 실제 fab/invoke 바이너리 main() (또는 무엇이든)의 매우 최소한의 호출자가 될 것입니다.

fabfiles와 "Invokefiles" 모두 2.0 이전 버전인 invoke + fabric 경로를 사용한다면? 지원되고 2.0에서는 Invoke 파일만 사용하시겠습니까?

따라서 본질적으로 나는 그것을 별개의 "태스크 러너"와 "원격/ssh 항목"으로 분할하고, 1.x에 대해 호환 심을 넣고, 2.x에 대해 더 이상 사용하지 않는 것에 대해 +1입니다. 이 분할은 두 라이브러리를 모두 더 좋게 만들고 작업 실행기가 정말 멋진 확장성을 지원할 것이라고 생각합니다(그리고 아마도 쉽게 의존하고 실행할 수 있는 외부 작업 등). 그리고 remote/ssh는 더 적은 책임을 가짐으로써 더 집중할 수 있는 이점이 있습니다.

어쨌든 내 센트.

나는 다른 방식을 싫어하지 않는다는 점을 분명히 해야 합니다. 이 토론이 진행되고 있어 기쁩니다. :)

@dstufft 많은 생각을 해주셔서 감사합니다. 거의 모든 부분에 동의합니다. 바이너리가 스텁이라는 것에 대해 당신이 옳습니다. 그것이 Fabric이 지금 작동하는 방식입니다. 제 관심사는 오로지 행동과 사용자 혼란에 관한 것입니다.

@dcolish CLI 확장을 할 수 없다는 의미는 아니었고, 코는 확실히 조사하기에 좋은 선행 기술입니다.

"invoke"를 사용하면 파일 이름이 invocations(.py) 가 될 수 있습니까? 어리석은/테마파크 측면에 대한 터치이지만 문법적으로 적합하며 invokefile.py 는 나에게 약간 어색하게 느껴집니다. 또는 Rake 컨벤션 경로로 이동하여 tasks(.py) 만 사용하십시오.

부분적으로는 관련이 있지만 앞으로의 모듈/폴더 측면에도 확실히 집중해야 한다고 생각합니다. Just Python이기 때문에 여전히 지원되지만 튜토리얼 자료 및 문서 측면에서 invocations/__init__.py 를 기본값으로 설정하는 것이 좋습니다.

tasks.py 을(를) 좋아합니다. invocations.py 는 입력하기가 이상합니다.

글쎄, 당신이 그것을 자주 입력해야 할 것 같지는 않습니다. 응? ;) 그러나 예, tasks/ 또는 tasks.py 는 전 세계적으로 조금 더 명확합니다.

작업파일.py

당신 invoke task(.py|/), 어쨌든 문구가 좋습니다 :)

예, " tasks which you invoke " 설정은 작동 방식에 대한 영어 설명과 키워드를 묶는 관점에서 매우 훌륭하게 작동합니다. 뻔하다, 프릴, 자만 등이 없다.

@kennethreitz 저는 명명 규칙으로 XYZFile의 열렬한 팬이 된 적이 없습니다. 특히 요즘에는 단일 파일이 아닌 경우가 많기 때문에 Fab 1.x 외부에서 규칙을 계속할 필요가 없습니다. :)

나는 이것이 일어나는 것을 완전히 보고 싶습니다. 저는 항상 Fabric을 로컬 기반이든 원격 기반이든 관계없이 Rake/Make에 가까운 프로젝트의 "작업"을 저장하는 일반적인 Pythonic 방식으로 보았습니다. 그러나 새로운 사람을 소개하려 할 때 몇몇 사람들은 이 관점에 대해 혼란스러워하고 배포 도구로만 보았습니다.

모듈/폴더 측면을 두 번째로, 드롭인 가능한 일반 작업을 더 쉽게 만들 수 있도록 하겠습니다. 새로운 스타일의 작업은 확실히 그 방향으로 나아갔습니다.

@askedrelic 예, 두 가지를 하나로 통합하는 것은 불행히도 항상 약간 혼란스럽습니다.

관련 없음: 몇 주 전에 그와 내가 이 문제에 대해 논의하고 있었기 때문에 이 스레드에 @tswicegood 을 호출하고 그가 무게를 달고 싶어할 수도 있다고 생각합니다. 평소와 같이 동의하지 않을 권리가 있습니다 ;)

내가 소환됐어? :-)

fabfile 대신 tasks 모듈로 이동하는 아이디어가 좋습니다. 더 의미가 있고 더 짧습니다. 일단 저는 Armstrong 내부에서 fab test 를 실행하기 위해 전체 dep 스택을 설치해야 하는 것을 싫어합니다. 그래서 제가 큰 장점이 되었다는 점을 추출하기 위해 할 수 있는 것은 무엇이든 할 수 있습니다.

명명에 관해서는 외부 실행 파일을 설치하는 것에서 사람들이 이것을 맨 아래에 추가하도록 하는 것으로 전환하는 것은 어떻습니까?

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

그런 다음 Python을 사용하면 됩니다. 실행 파일은 괜찮습니다. 필요한지 여부는 모르겠습니다.

FWIW, 나는 flunky 라는 패키지 생성을 처리하기 위해 몇 주 전에 프로젝트를 시작했습니다. 해당 테마를 고수하면서 footman 또는 lacky 를 모두 사용할 수 있습니다(후자는 Ruby 프로젝트인 lackie 와 충돌함). 또 다른 하나는 girl/man friday 에서와 같이 Friday 입니다. GitHub/PyPI/Homebrew 테스트를 통과했습니다. 사실 지금 생각해보면 그게 첫 번째 선택이 될 것 같아요.

부수적으로, @niran 이 명백하지만 끔찍한 주제가를 포함하도록 README를 업데이트하는 PR을 제출할 때까지 얼마나 걸릴지 궁금합니다.

내 생각에 $PATH "binary"(특히 현재 _not_ 실제 바이너리가 아니라 (invoked|fabric).main() 를 호출하는 setuptools 생성 스텁)가 가장 사용자 친화적입니다. , 그리고 작업 모듈 내에서 자동 생성되도록 해당 스텁의 내용을 이동하는 것에 대한 이점을 보지 못했습니다(실제로 많은 단점이 있음).

그리고 예, 이것의 요점은 SSH/네트워크/암호화 deps 없이도 작업을 수행할 수 있는 라이브러리로 끝나는 것입니다. :)

나는 실행 파일에 대해 @bitprophet 에 전적으로 동의합니다. 그것은 실행을 훨씬 쉽게 만듭니다. 누군가가 자신의 개인 프로젝트에서 invoke / fab 이외의 다른 것을 사용하려는 경우 이것은 스텁일 뿐이므로 쉽게 자신의 바이너리를 만들 수 있습니다(그리고 finalname.__main__.main 에서 쉽게 살 수 있습니다. , 이 경우 원하는 경우 python -m finalname 도 가능합니다.

+1.

거기에 아이디어를 던지는 것만으로도 더 편리한 것 같아요. FWIW, 사용하려면 PyPI에 금요일에 등록했습니다.

@bitprophet 죄송합니다. 진입점을 사용하는 방법을 알고 계신 것 같습니다. 나는 코와 비슷한 방식으로 프론트엔드를 만들고 이름을 fab으로 유지하기 위해 내 방식대로 투표했습니다.

아이디어는 훌륭합니다, 저는 아이디어를 좋아합니다 :)

금요일은 너무 귀여운 편에 속하지만 나는 대중 문화 참조를 좋아합니다. 그 노래가 너무 좋아요! :트롤페이스:

지금은 패키지/프로젝트와 바이너리 이름으로 invoke 를 그대로 사용할 것입니다. 요잉! Invoker 또는 Invoked는 전자에 대한 다른 가능성(즉, invoke 바이너리 사용)이지만 직접적인 경로를 선택하지 않을 타당한 이유를 생각할 수 없었습니다.

이 이름의 가장 큰 단점은 일반적이라는 점입니다. 하지만 이는 제가 인수하거나 생성한 모든 프로젝트의 문제이며 이 경우에는 더 구체적인 옵션이 저에게 옳다고 느껴지지 않았습니다. /정당화

@dcolish 인정, 감사합니다!

아직 최종 결정을 내리지는 않았지만 현 시점에서 합리적인 접근 방식은 다음과 같습니다.

• Invoke는 고유한 것, 고유한 새 ID/"브랜드", invoke 바이너리 사용, tasks 모듈 찾기 등입니다.
  
  
  
  • 이것은 Fabric이 아닌 Invoke만을 사용하는 사용자에게 개념적으로 깨끗하고 직관적이며 과거 수하물을 제거하는 등입니다.
  
  
• Invoke는 Fabric(또는 다른 도구)이 사용하려는 모든 공유 코드를 공개 API로 노출합니다.
• Fabric은 계속해서 fab 를 사용하고 fabfile 모듈을 찾고 Invoke에 대한 설치 시간 종속성을 추가하고 Invoke의 API를 사용하여 해당 공유 코드를 호출합니다.
  
  
  
  • 이것은 Fabric을 설치하면 두 개의 바이너리가 생성된다는 것을 의미하지만 Fabric에 초점을 맞춘 사용자의 관점에서 볼 때 invoke / tasks 가 존재하거나 옵션임을 _알_ 필요가 없습니다. d 절대 사용하지 마세요 -- fab 는 여전히 기능의 상위 집합입니다.
  
  
  • 자체를 위해 Invoke를 모두 사용하려는 사용자(예: Fabfile이 없는 다른 프로젝트에서) _및_ Fabric은 다시: invoke 및 fabric 이 서로 관련되고 행동하는 방식에 문제가 있습니다. . 이 사람들은 invoke 와 fab 가 서로의 단순한 별칭이라는 데 관심이 있을 수 있습니다(예: Fabric의 설치가 Nose 플러그인의 작동 방식과 같이 invoke 의 작동 방식을 변경하도록 함).
  
  
  • 그러나 나는 두 가지가 다르게 행동하도록 하는 것이 가장 좋다고 생각합니다 -- 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 저는 Invoke 위에서 작동하는 Fabric 2를 얻는 중입니다. Fabric 1에서 포팅되는 많은 기능은 Invoke에 대한 디자인 결정에 영향을 미치므로(새 기능 또는 기존 기능의 경우 - 예를 들어 최근 구성 정밀 검사가 이 중 하나임) Invoke 1.0이 " 충분히 검증된 전투"

내 계획은 Fabric 2의 알파를 PyCon에서 대중을 위해 준비하는 것이며(이상적으로는 훨씬 더 빨리) Fabric 2.0 + Invoke 1.0으로 이어질 것입니다.

설명 감사합니다. 어디에서 도움을 받을 수 있나요?

나는 내가 만족하는 것을 얻을 때까지 단기적으로 개인 지점에서 작업 중이며 피드백을 받을 준비가 되면 트위터/메일링 리스트/등에서 발표할 것이므로 계속 지켜봐 주시기 바랍니다.

패브릭이 내 프로젝트에서 python3 지원이 없는 마지막 패키지이기 때문에 쉘 명령 및 일부 Paramiko와 함께 호출하도록 전환하기 시작했습니다.

Fabric 2.0 및 Invoke 1.0 as Python 3.5에 대한 ETA가 어제 릴리스되었으며 Ubuntu 16.04 LTS의 기본값이 될까요?