Servo: 지원 상자 중 어느 것도 깔끔하게 확인되거나 라이선스가 확인되지 않습니다.

플랫폼 디렉토리에 비슷한 문제가 있습니다.

무시된 파일 목록을 보면 이렇게 할 수 있습니다.

https://github.com/servo/ 아래에서 포크가 아닌 것으로 정의될 수 있는 "우리" 코드 무리는 별도의 저장소에 있고 화물을 통해 사용되므로 tidy.py 에는 표시되지 않습니다. 그래서 이것은 완료되지 않았으며 이제 우리가 Cargo로 전환하고 모든 것이 하위 모듈이 되기 전보다 더 어렵습니다.

다른 구성으로 각 저장소에 깔끔하게 넣을 수 없습니까? 이러한 저장소는 모두 CI 시스템에 있어야 동일한 목적을 달성할 수 있습니다.

각 리포지토리에는 tidy.py 복사본이 있을 수 있는 자체 별도의 CI가 있지만, 이는 무언가를 추가하고 싶을 때 업데이트할 복사본이 많다는 것을 의미합니다.

서브 모듈로 깔끔하게 이동하시겠습니까? 다운로드하여 CI 중에 실행하시겠습니까? 그 문제를 줄이기 위한 몇 가지 방법이 있습니다.

고려할 옵션: tidy 를 PyPi에 servo_tidy 업로드하고 정리할 때마다 최신 버전을 다운로드하기만 하면 됩니다.

편집: 잭이 나를 이겼다.

@frewsxcv 그러나 나는 Corey의 제안에 대한 보다 구체적인 버전이 가장 좋습니다.

괜찮은. 나는 이것에 대해 잠시 생각했고 내가 도전할 준비가 되었다고 생각합니다. 나는 무엇이든 구현하기 전에 내 생각을 보고할 것입니다. 이것과 동시에 #6999를 고칠 수 있을지도 모릅니다.

몇 가지 생각 후 제안한 내용은 다음과 같습니다.

1. 가상 환경(웃음?). mach 명령을 실행하면 Python은 가상 환경을 생성/활성화합니다( .pyenv/ 또는 python/.pyenv/ ). 그런 다음 python/requirements.txt 파일에 따라 종속성을 설치/업데이트합니다. 이를 통해 트리에서 다음을 제거하고 PyPi 요구 사항으로 추가할 수 있습니다.
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

이것은 또한 #6999를 수정합니다. 빌더가 모든 빌드 후에 작업 디렉토리를 날려 버릴지 여부에 따라 Python virtualenv를 지정하기 위해 일종의 캐싱 옵션이나 mach 매개변수를 추가해야 할 수도 있습니다.

1. 패키지 tidy.py . 이것은 python/tidy/tidy.py 및 python/tidy/setup.py 생성하는 것을 의미할 수 있습니다.
2. tidy.py 를 다른 저장소에 통합합니다. 이를 수행하는 몇 가지 방법이 있습니다.
   
   
   
   1. PyPi에서 릴리스하십시오. Python 패키지가 변경될 때마다 자동으로 게시하는 시스템을 만들지 않는 한 배포하는 것은 고통스러울 수 있습니다.
   
   
   2. 다른 모든 저장소에서 다음을 수행하면 됩니다.
   
   

pip install -e git+https://github.com/servo/servo.git#egg=servo_tidy&subdirectory=python/tidy

다른 아이디어나 생각이 있는 사람이 있으면 알려주세요.

우리는 이미 web-platform-tests를 위한 virtualenv를 가지고 있으며 아마도 이것을 위해 사용될 수도 있습니다.

우리는 이미 web-platform-tests를 위한 virtualenv를 가지고 있으며 아마도 이것을 위해 사용될 수도 있습니다.

좋은 생각. tests/wpt/harness (wptrunner)를 트리 밖으로 옮기고 pip 종속성으로 만들 것을 제안하려고 했으나 트리 내 복사를 약간 수정한 것 같습니다.

이에 대한 업스트림은 https://github.com/w3c/wptrunner 이며 복사본에서 변경한 사항은 업스트림되어야 합니다. 서브 모듈이 아니거나 PyPI에서 설치한 이유를 모르겠습니다. 그러나 그것은 주제에서 벗어난 것이므로 자유롭게 다른 문제를 여십시오.

나는 생각했다 tests/wpt/_virtualenv (실행할 때 생성 된 ./mach test-wpt 하지) tests/wpt/harness .

또한 해당 _virtualenv가 더 많은 작업을 수행할 예정이라면(괜찮습니다) 아마도 트리 위로 더 높게 이동해야 합니다.

나는 tests/wpt/harness가 아니라 tests/wpt/_virtualenv(./mach test-wpt를 실행할 때 생성됨)를 생각하고 있었습니다.

맞아요. 새로운 가상 환경을 생성/활성화하는 Python 코드는 그리 많지 않으므로 미래에 WPT 요구 사항과 깔끔한 ​​요구 사항을 분리하려는 경우(비호환성 등으로 인해) 그렇게 어렵지 않아야 합니다.

나는 또한 virtualenv 경로를 python/_virtualenv 와 같은 보다 일반적인 장소로 옮기는 것에 반대하지 않습니다.

그리고 또 다시, 잭이 날 이겼어

python/_virtualenv 좋은 장소인 것 같습니다.

mach는 이제 #6999의 해상도 덕분에 python/_virtualenv 를 사용합니다.

서보 트리에서 패키지를 게시하는 이점은 결국 분할할 경우 다른 모든 저장소를 변경할 필요가 없다는 것입니다. 단점은 pypi에 대한 또 다른 자격 증명 집합을 관리하고 필수 변경 사항이 푸시되도록 해야 한다는 것입니다.

pypi에 게시하려면 pypi 계정의 사용자 이름과 비밀번호가 들어 있는 .pypirc 사본을 갖고 다음 명령을 실행하여 패키지를 등록하고 업로드합니다. 이 경우 "누군가"가 buildmaster 호스트인 경우 패키지 업데이트 프로세스를 자동화할 수 있습니다.

즉, pypi 또는 직접 설치에 문제가 없습니다. Pypi는 이제 더 많은 작업을 수행하고 직접 설치는 미래의 불확실한 시점에서 더 큰 번거로움이 있으며 둘 다 패키지로 정리해야 합니다.

@shinglyu , 깔끔하게 옮기고 파이썬 패키지로 설정할까요, 아니면 제가 할까요?

@edunham : 할 수 있어요. :)

내 동료 @askeing 은 이 문제에 매우 관심이 있으므로 이 문제는 그에게 맡길 것입니다.

안녕하세요 @edunham 입니다 .
https://github.com/askeing/servo_tidy 에서 Python 패키지(테스트 포함)로 설정하려고 합니다.

@askeing 감사합니다! 당신은 이미 대부분의 힘든 일을 한 것 같습니다. 내 유일한 요점은 setup() in setup.py 다음과 같은 것을 포함하는 것이 도움이 된다는 것입니다.

entry_points={
        'console_scripts': [
            'servo-tidy=servo_tidy:scan',
        ],
    },

패키지가 설치되면 다른 프로젝트의 .travis.yml 스크립트 섹션에서 직접 servo-tidy 호출할 수 있습니다.

@frewsxcv @larsbergstrom @metajack tidy 가 Servo 트리에 사는 것과 자체 저장소에 사는 것에 대해 어떻게 생각하십니까? 현재 트리에서 tidy git 기록을 유지하는 것이 프로젝트에 얼마나 중요한가요? 나는 개인적으로 가능하면 언제든지 역사를 유지하는 것을 선호하지만, 이 경우에는 필요보다 의견과 더 관련이 있습니다.

나에게서 강한 선호가 없다. tidy.py 는 일부 새로운 기여자의 출발점인 것으로 보이며 해당 파일을 별도의 저장소에 보관하면 해당 기여자의 장벽이 높아질 수 있습니다.

가장 중요한 관심사는 가능한 한 최소한의 중간 단계를 사용하여 Tidy.py를 수정하고 이러한 변경 사항이 ./mach test-tidy 어떻게 영향을 미치는지 확인하는 것이 가능하다는 것입니다.

죄송합니다. 그 PR에서 "수정"이라고 말하는 것은 조금 멀리 가고 있습니다. 상자는 아직 CI에서 실제로 사용하지 않습니다.

나는 이것이 지금쯤 중단되었거나 다른 문제가 이 문제를 대체했다고 확신합니다.