Nix 개발 환경은(는) 무엇을 하나요?

Nix 플레이크, nixpkgs unstable, devenv, direnv를 사용하여 프로젝트 개발 환경을 생성하고 유지 관리합니다. 플레이크의 공개 인터페이스를 작게 유지하고 셸 관련 세부 사항은 별도의 Nix 파일에 배치합니다.

상호 작용 계약

Nix 구성을 실행 가능한 프로젝트 정책으로 취급합니다. 암시적으로 수정하거나 활성화하지 마십시오.

먼저 저장소를 검사하고 제안된 변경 사항을 설명합니다.
파일을 생성, 편집, 이름 변경 또는 삭제하기 전에 명시적인 승인을 한 번 요청합니다. 관련 편집을 하나의 명확한 요청으로 그룹화합니다.
편집이 승인되고 완료된 후 검증 명령을 제안하고 명령을 실행하기 전에 별도의 승인을 요청합니다.
direnv allow를 이름을 명시하여 부르고 승인을 받지 않고 실행하지 마십시오. 이 명령은 프로젝트 구성의 자동 평가를 승인합니다.

사용자가 승인을 거부하는 경우 계획이나 명령만 제공하고 그 경계에서 중단합니다.

기본값 및 범위

새 작업에는 플레이크를 요구합니다. 프로젝트가 이미 다른 리비전을 고정하고 있고 사용자가 변경을 요청하지 않는 한 nixpkgs/nixos-unstable을 사용합니다.
모든 언어를 지원합니다. 프로젝트에 필요한 경우에만 언어 패키지, 포맷터, 린터, 서비스 및 환경 변수를 추가합니다.
nix develop 및 devShells.<system>.default를 이식 가능한 인터페이스로 선호합니다.
선언적 모듈, 서비스, 스크립트, 테스트 및 git 훅이 필요한 경우 devenv를 사용합니다. 어떤 것이 권위적인지 설명하지 않고 원시 mkShell과 devenv 모두에 중복 정의를 생성하지 마십시오.
요청되거나 프로젝트에서 이미 사용하는 경우에만 체크인된 .envrc를 통해 direnv를 통합합니다. 사용자의 로컬 전용 환경 설정을 유지합니다.
단순히 새로운 레이아웃이 선호된다는 이유로 기존 shell.nix, flake.nix, .envrc, devenv.nix, 잠금 파일 또는 CI 설정을 교체하거나 삭제하지 마십시오.

변경 제안 전 검사

최소한 다음을 찾습니다:

flake.nix, flake.lock, shell.nix, default.nix 및 nix/ 디렉토리
devenv.nix, devenv.yaml 및 .envrc
언어 매니페스트 및 잠금 파일, 포맷터/린터 구성, 테스트 러너 및 CI 워크플로우
설정 명령 또는 지원되는 플랫폼을 언급하는 프로젝트 문서

레이아웃을 제안하기 전에 기존 Nix 표현식을 읽습니다. 프로젝트에 이미 플레이크가 있는지, 지원하는 시스템, 종속성이 고정된 방식, devenv가 설치 또는 구성되었는지, direnv가 의도적으로 제외되었는지 확인합니다.

발견에 유용한 명령의 경우 nix flake metadata 또는 nix flake show와 같은 읽기 전용 명령을 선호합니다. 사용자가 명령 실행을 이미 승인하지 않은 경우 실행하기 전에 권한을 요청합니다.

파일 레이아웃

새 저장소 또는 간단히 구성된 저장소의 경우, 저장소의 기존 규칙이 더 나은 경우가 아니라면 다음 레이아웃을 제안합니다:

.
├── flake.nix
├── flake.lock
├── devenv.nix              # 사용 시 devenv 관련 모듈 및 서비스
├── .envrc                  # 사용 시 direnv 진입점
└── nix/
    └── devshell.nix        # 패키지, 변수 및 셸 훅

flake.nix에는 입력, 지원되는 시스템 플럼빙 및 내보낸 출력을 포함해야 합니다. mkShell 인수, 패키지 목록, 환경 변수 및 셸 훅은 nix/devshell.nix에 배치합니다. 셸이 상당히 커지면 nix/packages.nix 또는 nix/hooks.nix와 같이 nix/ 아래에 더 집중된 파일을 사용합니다.

새 설정에는 shell.nix를 사용하지 마십시오. 이미 존재하는 경우, 사용자가 마이그레이션 계획을 명시적으로 승인하지 않는 한 유지합니다. 마이그레이션 중에는 여전히 nix-shell을 실행하는 사용자에게 호환성 영향을 설명합니다.

설계 워크플로우

1. 현재 상황 설명

관련 기존 파일, 감지된 프로젝트 도구 및 불확실성을 요약합니다. 요구 사항이 불완전한 경우 다음과 같은 대상 질문을 합니다:

지원해야 하는 플랫폼(예: Linux만 또는 Linux와 macOS)?
셸 내에서 작동해야 하는 프로젝트 명령은?
데이터베이스 또는 기타 로컬 서비스가 필요한가요?
devenv가 환경을 소유해야 합니까, 아니면 devShell 주변에 기능을 추가해야 합니까?

2. 구현 제안

추가되거나 변경될 정확한 파일과 그 이유를 설명합니다. flake.lock이 변경될지 여부, .envrc가 생성 또는 편집될지 여부, 각 종속성을 소유하는 소스를 포함합니다.

새 범용 플레이크의 경우 명시적인 지원 시스템 전략을 사용하고 devShells.<system>.default를 노출합니다. 전체 mkShell 본문을 flake.nix에 배치하는 대신 별도의 셸 표현식을 가져옵니다. 초기 패키지 세트를 최소한으로 유지합니다. 템플릿이 완전해 보이도록 임의의 언어 도구 체인을 추가하지 마십시오.

사용자가 devenv를 요청하는 경우 설치된/버전 고정된 devenv 설정과 호환되는 통합을 선택합니다. devenv 선언은 devenv.nix(또는 가져오는 집중 파일)에 유지합니다. 사용자가 nix develop, devenv shell 또는 둘 다로 진입하는지 명확히 하고 문서화된 진입점이 조용히 분기되지 않도록 합니다.

direnv의 경우 프로젝트의 기존 규칙을 사용합니다. 플레이크 기반 .envrc는 일반적으로 nix-direnv 지원에 의존합니다. devenv 기반 .envrc는 적절한 devenv 통합에 의존합니다. 필요한 direnv 확장이 식별되지 않은 진입점을 작성하지 마십시오.

이것들을 별도의 사실로 취급합니다: nix-direnv가 설치되었는지 여부, 이 사용자의 direnv와 통합되었는지 여부, 이 프로젝트의 .envrc가 성공적으로 평가되는지 여부. 설치 확인을 위해 direnv stdlib(또는 출력에 use flake가 없는 것)를 사용하지 마십시오. 이는 해당 호출에 사용 가능한 표준 라이브러리를 반영하며 선언적 NixOS 또는 Home Manager 구성에 대한 권위 있는 정보가 아닙니다. 특히, 빈 direnv stdlib | grep -F 'use flake' 결과는 nix-direnv가 없다는 증거가 아닙니다.

발견이 승인되면 관련 증거를 검사하되 증명하는 바를 과장하지 마십시오:

NixOS 또는 Home Manager 구성을 사용할 수 있는 경우 programs.direnv.enable = true 및 programs.direnv.nix-direnv.enable = true(또는 동등한 모듈 구성)를 찾습니다. 이를 활성 셸이 로드했다는 증거가 아닌 선언적 구성으로 보고합니다.
nix-direnv와 direnv가 현재 환경에서 사용 가능한지 확인하고 액세스 가능한 경우 해당 direnvrc 또는 생성된 direnv 구성을 검사합니다. 사용할 수 없는 실행 파일이나 누락된 통합 파일을 사용자의 선언적 구성에 대한 주장이 아닌 현재 환경 관찰로 보고합니다.
프로젝트의 .envrc를 읽어 필요한 확장을 식별합니다. direnv status를 사용하여 현재 권한 부여/로드 상태를 검사합니다. 해당 프로젝트에서 평가될 때까지 use flake 진입점이 작동한다고 추론하지 마십시오.

명시적 승인 후에만 프로젝트 .envrc를 승인하고 테스트합니다. direnv allow가 신뢰 상태를 변경한다는 점을 명시하고, direnv reload 또는 direnv exec . <무해한-명령>을 실행하여 구성을 테스트합니다. 평가를 수행할 수 없는 경우 nix-direnv가 설치되지 않았다고 선언하는 대신 통합이 확인되지 않았다고 말합니다.

3. 편집 승인 획득

다음과 유사한 간결한 확인 요청을 사용합니다:

nix/devshell.nix를 추가하고, flake.nix를 업데이트하여 기본 dev 셸을 내보내고, devenv.nix와 .envrc를 추가/업데이트하고, 종속성 해결에 필요한 경우 flake.lock을 생성/업데이트하겠습니다. 이 편집을 진행해도 될까요?

긍정적인 답변을 기다립니다. 제안된 작업이 승인된 계획과 다른 경우 추가 편집을 하기 전에 다시 물어봅니다.

4. 신중하게 편집

서식과 로컬 명명 규칙을 유지합니다. 주석은 Nix 구문을 반복하기보다는 명확하지 않은 제약 조건에 초점을 맞춥니다. flake.lock을 통해 플레이크 입력을 고정합니다. 잠금 파일 대신 부동 URL을 사용하지 마십시오.

셸 패키지를 추가할 때는 프로젝트의 고정된 pkgs에서 제공하는 패키지를 선호합니다. 사용자가 명시적으로 요청하고 승인하지 않는 한 무료가 아닌 패키지, 안전하지 않은 패키지 허용, 바이너리 캐시 또는 대체자 구성을 피합니다.

5. 검증 제안 및 별도 승인 획득

편집 후 관련 명령만 나열하고 목적을 설명하며 승인을 요청합니다. 다음 중에서 선택합니다:

nix flake check
nix flake show
nix develop --command <프로젝트-확인-또는-도구-버전-명령>
devenv test
devenv shell -- <프로젝트-확인-또는-도구-버전-명령>
direnv allow

가능한 경우 셸 진입 확인에 무해한 명령(예: 필수 도구의 --version 또는 프로젝트 포맷터의 확인 모드)을 사용합니다. 명령을 실행하기 전에 예상되는 네트워크 액세스, 빌드, 다운로드 또는 잠금 파일 업데이트를 설명합니다. 사용자가 명시적으로 요청하지 않는 한 nix flake update, 광범위한 가비지 수집, 저장소 삭제 또는 프로필 변경 명령을 실행하지 마십시오.

6. 결과 보고

변경된 파일, 진입 명령, 검증 결과 및 남은 수동 단계를 명시합니다. 예를 들어, .envrc를 검토한 후 사용자가 nix develop, devenv shell 및/또는 direnv allow를 실행해야 하는지 식별합니다.

문제 해결 원칙

핀을 변경하거나 재정의를 추가하기 전에 실제 오류를 재현하고 검사합니다.
평가 실패, 누락된 속성, 플랫폼 지원 문제, 빌드 실패 및 런타임 종속성 문제를 구분합니다.
unstable 패키지가 존재하거나 예상된 이름을 가지고 있다고 가정하기 전에 고정된 입력과 패키지 속성을 확인합니다.
전역 Nix 구성 변경보다는 작고 문서화된 수정을 선호합니다.
변경 사항이 재현성이나 모든 기여자에게 영향을 미칠 수 있는 경우 대안을 제시하고 편집 전에 승인을 요청합니다.

완료 기준

구성이 모듈화되어 있고, 선언된 진입점이 최종 응답에 문서화되어 있으며, 요청된 검사가 통과되었거나 그 결과가 명확하게 보고되었고, 모든 편집 및 검증 명령이 필요한 승인을 거친 경우에만 작업을 완료된 것으로 간주합니다.

Nix 개발 환경