0
조직 용 gitlab 설치가 있습니다. 표준화하기 위해, 프레임 워크와 개발 과정에서 우리는 우리의 서버에 우리 자신의 packagist 설치를 사용하고자합니다. 나를 혼란스럽게하는 것은 gitlab의 repo에있는 패키지를 제출해야 할 때 인증을 요구하는 것입니다. composer.json에 패키지를 포함시키면서 거기에서 패키지를 읽을 수 있도록 repo, 사용자 이름 및 암호를 넣을 수 있습니다. 나는 프로젝트를 만드는 오전 중에 나 : 그게 사실이라면gitlab 패키지 전문가 용 호스트 개인 PHP 패키지
composer create-project vendor/name path --repository-url=http://user:[email protected]/myrepo/package.git
을, 우리는 정말 packagist 필요합니까? 그렇다면 무엇을 설치하는 것이 가장 좋은 방법일까요? packagist (우리 호스팅)에서 패키지 제출이 어떻게 작동하는지 말해 주시면 감사하겠습니다.
비공개 패키지에 대한 모든 작성기 정보의 로컬 메타 데이터 저장소가 필요합니다. 그렇지 않으면 패키지를 포함 할 수있는 모든 저장소를 전이 패키지 관계에서도 루트 애플리케이션의 모든'composer.json' 파일에 포함시켜야합니다. 고려해야 할 또 다른 사항 : 모든 사람과 배포 시스템에 모든 항목을 복제하도록 요구하는 대신 태그가 지정된 버전 용 ZIP 파일 제공. Packagist를 로컬 설치에서 사용할 수 있다면 기능을 필요로하지만, 120 개의 내부 패키지와 300 개 이상의 외부를 호스팅하는 Satis를 사용하면 여전히 만족합니다. – Sven
@Sven 그럼 개인 패키지를 유지하기 위해 Packagist 대신'satis'를 사용하고 있습니까? 이 접근법의 장점은 무엇입니까? 나는 단지 packagist를 사용하고 싶지 않다. 나는 그것과 똑같은 것을 느낀다. 단지 소프트웨어가 다르다. – SAM
Satis는 본질적으로 "스크립트를 실행하고 정적 출력을 생성 한 다음 상상할 수있는 가장 기본적인 웹 서버에서이 출력을 호스트합니다". 일종의 데이터베이스를 사용하고 적어도 서버에서 PHP를 요구하는 packagist와 비교합니다. "Satis는 단 한 번에 모든 것을 업데이트 할 수 있습니다"라는 단점이 있습니다. 이는 우리에게 약 5-8 분이 걸립니다. Packagist는 트리거 된 하나의 패키지를 가져올 수 있으며이 패키지 만 업데이트합니다. 세 번째 대안으로 https://toranproxy.com을 살펴 봐야합니다. – Sven