통과"설치 패키지"내 말은 Nix 빌드 표현식( 등을 사용하여)을 평가하는 것이 를 사용하는 대신 소스 코드에서 빌드된다는 것 입니다 nix-env.nix-shell -p바꾸다.
처음에는Stackoverflow에 게시됨그러나 [Charles Duffy는][3] 명령줄 도구나 구성에 관한 것이라면 여기가 더 적합하다고 지적합니다. 여전히 그대로 둡니다. Nix 언어 자체를 사용하면 패키지가 항상 소스에서 컴파일되도록 강제할 수 있다고 가정하기 때문에 아직 방법은 모르겠습니다. (또는 실제로 가능하지 않은데 누군가 지적한다면 질문은 여기에 속합니다.)
답변1
어느 쪽이든 설정substitute옵션false~에nix.conf(기본값 true) 또는 --option substitute falseNix 명령을 호출할 때 사용됩니다.
nix-env --options substitute false -i hello
nix-shell --options substitute false -p hello
당신이 찾고 있는 로봇이 아닐 수도 있습니다.
로버트 헨싱(논평,채팅), 헨리 멘케(논평) 및 블라디미르 추누트(논평)는 이것이 실제로 원하는 것이 아닐 수도 있음을 지적합니다.
자세히 설명하자면, 저는 항상 가장 기본적인 Nix 기능 사용에 자신감을 갖고 있었지만, C로 작성된 대규모 애플리케이션의 사용자 정의 포크를 유지 관리하고 배포해야 하는 지점에 도달하는 것은 처음에는 매우 겁이 났습니다.
가장 간단한 방법으로 문제를 해결해 보세요.가져와나는 그것을 포크하고 새로운 소스 코드로 다시 빌드했기 때문에 이 문제가 원인이라고 생각했습니다. 하지만 나에게 올바른 방향은 다음과 같습니다.Nixpkgs/패키지 생성 및 디버그내부에NixOS 위키.
패키지 자체만 다시 빌드하세요.
블라디미르 쿠나트 댓글저것"대안을 비활성화하면 로컬에서 누락된 모든 항목을 다시 빌드할 수 있습니다. 하지만 이와 같은 질문을 하는 사람들은 일반적으로 지정된 패키지 자체만 다시 빌드하려는 것 같습니다."
(이것은 다음과 같이 달성할 수 있습니다.nix-build또는 "그냥"은 원래 패키지를 덮어쓰지만 틀릴 수도 있습니다. 후자는 NixOS 위키 기사에 언급되어 있습니다.개발 환경과nix-shell그러나 나는 아직 그것을 완전히 이해하지 못했습니다. )
테스트 재현성
사람들은 후속 빌드가 결정적인지 확인하려는 경우 동일한 질문을 할 수 있습니다. ~처럼헨리 멘케의 논평nix-build --check, 이 목적 으로 사용해야 합니다 .
이 --check옵션은 놓치기 쉽습니다.man nix-build또는nix-build내부에닉스 매뉴얼, 그러나 왜냐하면 nix-store --realize(예를 들어man nix-build설명하다):
nix-buildnix-instantiate본질적으로 (고수준 Nix 표현을 저수준 저장소 파생으로 변환) 및 (저장소 파생 구축) 을 둘러싼 래퍼입니다nix-store --realise. 따라서 여기에 나열되지 않은 모든 옵션은 및 / 를nix-store --realise제외 하고 에 전달됩니다 .--arg--attr-Anix-instantiate
자세한 예는 다음에서 확인하세요.닉스 매뉴얼존재하다18.1 확실성을 높이기 위한 즉석 점검그리고다음 부분은 다음과 같습니다.
구성 옵션 관련 부분은 substitute다음과 같습니다.이 nix.conf부분~에서닉스 매뉴얼:
이름
nix.conf— Nix 구성 파일설명하다
Nix는 두 가지 구성 파일에서 설정을 읽습니다.
시스템 전체 구성 파일
sysconfdir/nix/nix.conf(예:/etc/nix/nix.conf대부분의 시스템) 또는 이미 설정된$NIX_CONF_DIR/nix.conf경우 .NIX_CONF_DIR사용자 프로필
$XDG_CONFIG_HOME/nix/nix.conf또는 설정되지 않은~/.config/nix/nix.conf경우XDG_CONFIG_HOME.
--option플래그를 사용하여 명령줄에서 설정을 재정의할 수 있습니다.,예를 들어--option keep-outputs false.현재 다음 설정을 사용할 수 있습니다.
[..]
바꾸다
true(기본값)로 설정하면 Nix는 가능한 경우 바이너리 대안을 사용합니다. 이 옵션을 비활성화하여 소스에서 강제로 빌드할 수 있습니다.
(원래 이름 use-binary-caches.)
노트
이것을 (with 또는 in) substitute로 설정하면 명령이 여러 번 실행되는 경우 패키지가 다시 컴파일되지 않습니다 . 즉, 위 명령은 처음에는 소스에서 컴파일한 후 다시 명령을 실행하면 이미 존재하는 저장 경로에 액세스하게 됩니다.false--optionsnix.confhello
이것이 모호해지는 부분입니다. 패키지의 Nix 빌드 표현식이 변경되지 않는 한 저장된 출력 해시도 변경되지 않아 다음 컴파일 출력이 이전 컴파일 출력과 동일해지기 때문에 재컴파일은 발생하지 않습니다. 그러므로 중복됩니다.
따라서 누군가가 패키지에 대해 가벼운 해킹을 수행하고 로컬에서 시도하고 싶다면( 예: 다음을 nix-shell사용) -I nixpkgs=a/local/nixpkgs/dir아니면 사용해야 합니까 nix-build?
질문도 참조하세요nix-build상점 경로를 다시 작성하는 방법은 무엇입니까 ?