swift 에서는 cocoapods 의존성 도구로 많이 쓰였는데 나중에 carthage라는 도구가 탄생하게된 배경이 되었습니다. carthage 개발자는 simple과 easy의 차이로 설명하더군요. https://academy.realm.io/posts/swift-dependency-management-with-carthage/
의존성 관리 도구를 안쓸 수는 없을거 같고 얼마나 효율적으로 관리되느냐가 관건일것 같아요. 저도 의존성 붙였다가 고생한 경험이 여러번 있어서 의존성 패키지 도입시 고민 좀 하는 편입니다.
쓰는게 더 골치아픈 경우도 있죠.
리뷰 부탁드립니다.
moving parts 라는게 멀 말하는건가요?
functional flow 절이 있는 걸로 봐서는 방향을 의미하는 것 같기도 한데요 확실치가 않네요.
Hmm... 중간에 번역이 날아가 버렸네요. :worried:
The solving function checks the existing
Gopkg.lock
to determine if all of its inputs (project import statements +
Gopkg.toml
rules) are satisfied. If they are, the solving function can be bypassed entirely. If not, the solving function proceeds, but attempts to change as few of the selections in
Gopkg.lock
as possible.
WIP: The current implementation's check relies on a coarse heuristic check that can be wrong in some cases. There is a plan to fix this.
The vendoring function hashes each discrete project already in
vendor/
to see if the code present on disk is what
Gopkg.lock
indicates it should be. Only projects that deviate from expectations are written out.
WIP: the hashing check is generally referred to as "vendor verification," and is not yet complete.
Without this verification, dep is blind to whether code in vendor/ is correct or not; as such, dep must defensively re-write all projects to ensure the state of vendor/ is correct.
The solving function checks the existing
Gopkg.lock
to determine if all of its inputs (project import statements +
Gopkg.toml
rules) are satisfied. If they are, the solving function can be bypassed entirely. If not, the solving function proceeds, but attempts to change as few of the selections in
Gopkg.lock
as possible.
WIP: The current implementation's check relies on a coarse heuristic check that can be wrong in some cases. There is a plan to fix this.
The vendoring function hashes each discrete project already in
vendor/
to see if the code present on disk is what
Gopkg.lock
indicates it should be. Only projects that deviate from expectations are written out.
WIP: the hashing check is generally referred to as "vendor verification," and is not yet complete.
Without this verification, dep is blind to whether code in vendor/ is correct or not; as such, dep must defensively re-write all projects to ensure the state of vendor/ is correct.
무슨 문제인지 문장을 translation string으로 인식하지 못해서 일어나는 현상 같아요.
visible 처리했습니다.
음. 그것보다 큰 문제는 해당 문장이 분리되어 있는게 더 문제네요.
The solving function checks the existing
이 문장과
to determine if all of its inputs (project import statements +
Gopkg.toml
왜 이렇게 분리가 된건지 모르겠네요.
https://crowdin.com/project/golang-dep/settings#strings 이쪽에서 수동으로 수정을 해야할까요?
이런… md 파일 editing 이 지원되지 않네요.
GM! BTW
crowdin 채팅에 물어볼까요?
암만 봐도 이상함.
문장을 왜 저렇게 쪼개놓은 건지..
제가 visible로 처리했는데 왜 다시 이렇게 되어있는건지.
일단 물어보겠습니다.
아닌거 같은데..
개인적으로 hidden string 처리하는 로직에 문제가 있어서 전체가 다 이렇게 된 거 같기도 한데요.
md 의 경우 length 와 dot(`)을 기준으로 string 을 쪼개는 기준으로 삼는다고 하네요.