업데이트된 프로젝트 맵을 하위 작업으로 전파

묘사

update-in가 방금 출시되었기 때문에 이 제의의 시기는 매우 불행하지만, 나는 그래도 토론을 하고 싶다.
우리는 이 약속에 따라 임무를'포장 결과'로 되돌릴 수 있는 약속을 도입할 수 있다.

^:boxed-result {:result normal-result
                :project updated-project-map}

do 및 기타 고급 작업은 되돌아오는 항목을 모든 하위 작업에 비추어 이 프로토콜을 지원합니다.이렇게 하면 퀘스트 체인 관심사 중'프로젝트 맵 업데이트'관심사 선택을 취소하여 update-in에서 다음과 같은 혜택을 얻을 수 있습니다.
1. 모든 고급 퀘스트는 가입할 수 있습니다(예를 들어thrush).
2. 모든 사용자가 공헌한 퀘스트는 진정으로 임의의 방식으로 프로젝트 지도를 업데이트할 수 있습니다.update-in 자체의 문법은 더 이상 높은 임무가 될 수 없기 때문에 간소화되었다.
우리는 update-in 프로토콜에 즉시 적응할 수 있기 때문에 현재의 핫이슈이자 갱신 프로젝트를 되돌려주는 임무로서 이중적인 역할을 한다.
우리는 또한 do 어떤 내용도 파괴하지 않는 상황에서 이 협의를 지원할 수 있다. 왜냐하면 이 협의는 모든 정상적인 반환 값이 정상적으로 작동하고 boxed-result 주석이 있는 결과에만 특수한 행위를 적용하기 때문이다.
만약 내가 이 점에서 공감대를 형성한다면, 나는 즉시 실시할 수 있다.

토론 #1

복잡하게 들린다.프로젝트 지도에서 조작을 하는 것은 임무의 진정한 목적이 아니기 때문에 나는 임무(부작용)와 지도 조작을 두 개의 단독 구성 요소로 나누는 경향이 있다.
나도 사람들이 이 결과를 어디에서 사용할지 완전히 확실하지 않다.플러그인을 사용하고 중간부품을 이용해서 프로젝트 맵을 수정할 수도 있고, 필요하면 플러그인의 다른 작업을 직접 호출할 수도 있습니다.
이것이 어디에 쓸모가 있는지 알려주고 내가 잘못하고 보수적이라는 것을 증명해 주십시오.) 나는 내가 무엇을 놓쳤다고 확신합니다.

토론 #2

@hyPiRion 나는 이것이 논쟁의 특성이라는 것을 완전히 알고 있다. 나는 주로 내가 그것에 대한 사용 사례를 토론하고 우리가 이런 식이나 다른 방식으로 그것을 지지할 수 있는지 확인하고 싶다.
내가 연구하고 있는 용례는 '작으면 아름다움', 조합할 수 있는 liningen 작업으로 사용자가 자신의 맞춤형 부품/패키지 발표 과정을 지정할 수 있도록 하는 것이다.이 과정에서 중요한 단계는 프로젝트 버전을 업그레이드하기 위해 편집project.clj하는 것이다.알다시피 이것은 자주 잊혀지는 절차이다. 어쨌든 다음 절차를 완전히 손으로 완성하는 것은 무미건조하다.
1. 삭제 - 스냅샷 버전 한정자;
2. 공작물 배치;
3. 프로젝트를 제출합니다.clj는 이 버전과 함께 발표하고 발표를 표시한다.
4. 충돌 주요/부차/복원 버전;
5. 스냅샷 제한 문자를 복원합니다.
6. 이 변경 사항을 사용하여 다시 제출합니다.
하나의 방법 (현재 내 방식) 은 모든 절차를 완성하기 위해 하나의 발표 플러그인을 사용하는 것이다.그러나 이런 방법은 유연성이 없기 때문에 특정한 설정 옵션을 많이 사용해서 유연성을 높여야 한다.다른 한편, 만약 우리가 일련의 편집 버전, 배치, 제출 프로젝트의 작은 임무를 가지고 있다면.clj 등, 사용자는 :aliases 도구를 이용하여 독특한 발표 과정을 작성할 수 있으며, 설정 옵션을 불러올 필요가 없습니다.
이제 항목의 작업을 편집합니다.clj는 분명히 이런 변화를 하류 임무에 전달해야 한다.내가 이곳에서 건의한 것은 그것이 이렇게 하는 것을 허락하는 것이다.

토론 #셋

@mtopolnik 저는 발표 스크립트를 사용하여lein 작업을 작성하기 때문에 작고 아름다운 방법을 좋아할 것입니다.나는 단지 너에게 lein-set-version 버전 번호를 업데이트하려고 한다. project.clj 뿐만 아니라 README.md와 다른 버전이 포함된 .clj 파일(예를 들어lein 플러그인 코드에 사용된 프로필)에서도 버전 번호를 업데이트하고 싶다.또한 @dGized와git 흐름을 기반으로 하는lein 플러그인을 추가하는 과정을 논의했습니다.
우리는 매우 기꺼이 위에서 합작을 진행할 것이다. 왜냐하면 우리는 대량의 발표 각본이 있기 때문이다.

토론 #4

@hugoduncan I도 발표된 셸 스크립트에서 시작하지만, 이를 리닌 작업 중 몇 가지 매력적인 곳으로 이식합니다.
-shell 스크립트는 다시 사용하기 쉽지 않습니다.대부분의 경우, 스크립트를 새 프로젝트로 복사하고 단독으로 유지하기만 하면 됩니다.
- 간단한 셸 명령보다 재미있는 원어가 있다.
- 이 원어들은 셸 스크립트로 완성할 수 있지만 단독 버전 제어 시스템이 필요합니다.
- 명령마다 다시 호출하는 것보다 leiningen 호출에서 모든 내용을 실행하는 것이 훨씬 빠르다.
- 작업lein-thrush을 수행하여 한 단계의 결과를 다음 단계로 이동할 수 있습니다.
나는 복습한 적이 있다lein-set-version.그것은 약간의 좋은 생각이 있는데, 나는 아마도 나의 관점에서 구현하고 싶을 것이다.나의 방법의 관건적인 차이점은, 나는 계산을 통해 판본을 명확하게 제시하지 않기를 바란다는 것이다.내 생각은 이렇다.

lein bump-version (:major | :minor | :fix | :qualifier) [:snapshot]

어쨌든 lein-set-version도 이 문제에 대한 나의 건의에 도움이 될 것이다. 왜냐하면 이것은 임무 체인을 통해 그 유용성을 높일 수 있기 때문이다.동의하십니까?
합작에 관해서 나는 전적으로 찬성한다.나는 나의 모든 임무를 하나의 플러그인 프로젝트에 통합시켜서 내 자신의 do와 thrush를 작성해서 이 제의를 실현해야 한다. 그러면 우리는 유용한 방법을 모색하는 출발점이 될 것이다.

토론 #5

이것은 재미있는 용례이다.새로운 패키지 결과 형식을 도입하는 것보다 업데이트된 항목을 반환값의 메타데이터로 선택적으로 되돌려주고 싶습니다.물론, 이것은 당신을 IObj 개의 값으로 제한하지만, 관심이 없다면, 그것은 더욱 간단하고 무시되기 쉽다.

토론 #6

@technomancy 무슨 말인지 알겠어요.나는 또 세부 사항을 좀 더 토론하고 싶다.
1. 나의 건의하에 결과는 여전히 하나의 규칙도일 뿐이다. 그것은 기존의 고급 임무를 파괴해서는 안 된다.
2. 만약에 하위 임무가 간단한 결과가 아니라 이런'박스 결과'그림을 받고 그 위에서 중단한다면 이것은 실제적으로 더욱 좋을 것이다. 왜냐하면 하위 임무의 고장을 피할 수 있기 때문이다. 그렇지 않으면 유행이 지난 프로젝트 도면에 작용할 수 있기 때문이다.
3. 당신과 나의 제의에 따라 맡은 고급 임무는 협의를 이해해야 합니다.그렇지 않으면 프로젝트 업데이트 작업 아래에 표시하려는 모든 작업은 특수 구조를 수동으로 검사하고 업데이트를 적용해야 합니다.
따라서 제 제안에 따라 규정 준수 및 규정 위반 HOT가 제공됩니다.부적합한 HOT는 여전히 프로젝트 업데이트 작업을 호출할 수 있지만 변경 사항을 적용할 수 없으며 오류 결과가 다음 작업으로 전송될 수 있습니다.몇 개의hot만 있기 때문에 코드를 조금만 수정할 수 있습니다.
당신의 제안에 핫한 지원이 없다면, 거의 모든 (저급) 작업이 최종적으로 요구에 부합되지 않을 뿐만 아니라, 모든 작업에 업데이트된 템플릿 코드를 추가해야 한다.
당신은 어떻게 생각합니까?thrush 어쨌든 나는 먼저 이런 방법을 시험해 보고 그것이 몇 마일을 뛸 수 있는지 본 후에 다시 돌아와서 레닌건에게 요구를 해야 한다고 생각한다. 만약 내가 이것이 가치가 있다고 생각한다면.

토론 #7

@hugoduncan 나는 내가 현재 걸고 있는 프로젝트lein-nix에 대해 초보적인 약속을 했다.주간은

토론 #8

과xdo로 둘 다 상술thrush약정을 지지한다.이 밖에 그들은 어떻게 치료^:boxed-result 이후에 발생했는지xdo와 반대로도 마찬가지였다.나의 생각은 의미를 일련의 고급 임무로 정의하는 것이기 때문에 새로 나타난 thrush/xdo 이후의 모든 매개 변수가 그것에 전달될 것이다.thrush 죄송하지만 포장된 결과는 개념적인 비용이 너무 많아서 표준으로 인코딩할 수 없습니다.
이를 지원하는 두 가지 방법이 있습니다.
- 프로젝트 맵을 변경해야 하는 퀘스트는 프로젝트 맵을 업데이트해야 하는 퀘스트를 호출합니다.
- 작업을 새 항목으로 되돌려 주거나 다른 값이 아닌 새 항목으로 되돌려 줍니다.

토론 #9

작업이 업데이트되어 이를 감지하거나 다른 링크 플러그인을 사용할 수 있습니다.do 제가 현재 lein-nix에서 처리하는 방식은 다음과 같습니다.

(defn edit-version
"Updates the project version by editing project.clj.

Required argument: a vector [curr-v new-v]"
  [project [curr-v new-v]]
  (when-let [new-prj (update-project! project new-v)]
    ^:boxed-result {:result new-v, :project new-prj}))

나는 맞춤형 열 xdo가 하나 있다.

(defn ^:no-project-needed ^:higher-order xdo
  "Just like the regular do, but propagates changes to the project map.

Each comma-separated group should be a task name followed by optional arguments.

USAGE: lein xdo test, compile :all, deploy private-repo"
  [project & args]
  (with-meta (zipmap [:project :result]
                     (reduce (fn [[project] arg-group]
                               (->> (resolve-and-apply project arg-group)
                                    (prj-result project)))
                             [project] (group-args args)))
    {:boxed-result true}))

따라서 만약에 제 용례 외에 이 특성이 필요하지 않다면 사용자 정의 HOT를 제 라이브러리의 일부로 삼는 것은 틀림없다고 생각합니다.