저는 패키지의 유지자인 lrucache입니다. 최근 Binary 및 NFData에 대한 인스턴스 추가 기능 요청이 접수되었습니다. 두 가지 모두 가지고있는 유용한 것들이며, 원칙적으로 그러한 경우에는 아무런 문제가 없습니다.새 패키지 종속성을 추가하는 기능 요청을 처리하는 방법
그러나 둘 다 새로운 패키지 종속성을 도입하고 패키지의 종속성 목록을 가능한 한 최소화하고 싶습니다. 이 문제를 처리 할 정상적인 방법이 있습니까? lrucache의 데이터 구조가 유용한 유형 클래스를 제공하는 20 가지 이상의 패키지가 있으며 구현할 수 있으며 이점을 얻을 수 있습니다.
분명히 모든 항목을 종속 항목으로 추가하는 것이 비 스타터입니다. 그러나 그 밖의 무엇을 할 수 있습니까?
lrucache.cabal에 다양한 인스턴스를 컴파일 할 수있는 플래그를 추가 할 수 있습니다. 의존성 목록을 최소화하려는 측면에서, 원하는 경우를 제외하고는 효과가 있습니다. 하지만 실제 상황에서는 끔찍한데, 왜냐하면 빌드에 의존하는 섹션에서 빌드 플래그를 지정할 수 없기 때문입니다. 따라서 특정 플래그가있는 패키지에 의존 할 수는 있지만 종속성은 지정하지 마십시오. 이것은 곧 거의 쓸모없는 것으로 줄어 듭니다.
고아 인스턴스 패키지를 만들 수 있습니다. 이것은 build-depends 섹션에서 이들 인스턴스에 대한 종속성을 지정할 수있는 이점이 있습니다. 가장 큰 단점은 해킹에 추가 패키지를 추가하는 것입니다. 패키지를 별도의 패키지로 유지해야합니다.
그 밖의 무엇을 할 수 있습니까? 무엇이 옳은 일입니까?
"고아 인스턴스 패키지"접근 방식은 적어도 일반적인 전략 인 것으로 보입니다. 해야 할 일은 아마도 더 나은 의존성 관리를 고안하는 것이지만 ... –
@C. A. McCann, 저는 소프트웨어가'./configure --enable-Z'를 사용할 때 그것을 개인적으로 싫어합니다. 나는 물건을 간단하게하는 것을 좋아한다. - 설치 한 것으로 표시된 패키지는 그것이 설치되어 있음을 의미한다. "옵션 X와 Y가 있지만 Z가 아닌 것은 설치되어 있지 않다". 아마 Hackage가 인스턴스 패키지를 고아로 만들 수는 있지만, 개념이 불법이라고 생각하지는 않습니다. – gatoatigrado
@gatoatigrado : 동의합니다. 그들을 더 잘 조직하는 Cabal은 내가 언급 한 것처럼 "더 나은 의존성 관리"의 자격을 갖게 될 것이므로 자유롭게 그것을 고안하십시오. :] 나는 그런 시스템을 구현하는 데있어 장애물이 무엇인지 잘 모르겠습니다. –