Python

<blockquote>macOS 사용 도중 파이썬 패키지를 설치하기 위해 pip를 사용하자 보안 경고가 발생하며 설치가 거부되었다. 이를 해결하는 방법에 대해 다룬다.</blockquote><h3>도대체 무슨 에러인가?</h3><img src="https://image.until.blog/xeros/article/1727225853116.png" alt="until-1518">Python의 최신 PEP 668 표준에 의해, macOS 환경에서 pip를 통한 패키지 설치가 제약되는 문제라고 한다. 아무래도 최근에 애플에서 맥에 여러가지 보안 강화 조치와 제약이 추가되었는데 여기에 영향을 받은 패치가 아닐까 싶다.이 문제를 해결하는 방법은 크게 3가지정도로 구분할 수 있다.<h3>1. 가상 환경을 사용하는 방법</h3>다음과 같이 Python 가상 환경을 만들어서 사용하면 독립된 공간을 만들어서 사용하기에 pip를 정상적으로 사용할 수 있게 되며 패키지의 버전 문제로 인한 충돌을 피하기도 쉽다. 하지만 매 파이썬 프로젝트마다 가상 환경을 생성해주어야하고 터미널을 열 때마다 <code spellcheck="false">source</code>를 지정해 주어야 한다는 번거로움이 따른다.<ol><li>가상 환경 생성</li></ol><pre spellcheck="false"><code class="language-bash">python3 -m venv path/to/venv</code></pre><ol start="2"><li>가상 환경 활성화</li></ol><pre spellcheck="false"><code class="language-bash">source path/to/venv/bin/activate</code></pre><ol start="3"><li>패키지 설치</li></ol><pre spellcheck="false"><code>pip install supabase</code></pre><h3>2. pip에서 사용자 플래그 추가</h3>시스템 패키지 환경을 보호하기 위해 설치를 사용자 환경으로 제한하여 설치하도록 한다.그냥 귀찮음도 덜하고 보안도 챙기고 무난한 방법인듯하다.<pre spellcheck="false"><code class="language-bash">pip install --user supabase</code></pre><h3>3. break-system-package 옵션 또는 pip.conf 수정</h3>그냥 보안 권고사항을 무시하고 기존에 pip처럼 다이렉트 설치를 가능하게 하는 옵션을 붙여서 사용하면 된다.<pre spellcheck="false"><code class="language-bash">pip install &lt;package name&gt; --break-system-packages</code></pre>근데 매번 이 옵션을 붙이는것도 귀찮다면 아예 <code spellcheck="false">pip.conf</code> 파일을 수정해서 영구적으로 해당 명령을 활성화 시키는것 역시 가능하다.<ol><li><code spellcheck="false">pip.conf</code> 파일 생성</li></ol><pre spellcheck="false"><code class="language-bash">mkdir -p ~/.config/pip
vi ~/.config/pip/pip.conf</code></pre><ol start="2"><li>아래 내용을 추가한다.</li></ol><pre spellcheck="false"><code class="language-bash">pip install supabase --break-system-packages</code></pre><h3>왜 이런 보안조치가 시행되었는가?</h3>애플이 원래도 보안쪽으로는 깐깐했지만 갑자기 이런 기존 시스템에 영향을 줄 수도 있는 패치를 한 원인이 궁금해서 찾아보니 간략하게 설명하자면 pip를 사용한 시스템 전역 패키지 설치가 운영 체제의 패키지 관리자와 충돌할 수 있어 이를 방지하려는 목적이라고 한다. 패키지를 가상 환경이나 사용자 환경에만 설치하도록 유도해서 종속성 관리 문제를 해결하고 보안 취약점을 줄이기 위한 조치인듯 하다.마찬가지로 <code spellcheck="false">Homebrew</code> 역시 현재 공식 홈페이지에 나와있는 Installation 방법을 따라하고 추가적인 수정을 거치지 않으면 명령어 인식이 안된다.

macOS에서 pip externally-managed-environment 에러를 픽스하는 방법

macOS에서 pip install시 error: externally-managed-environment 에러가 발생하는 문제

- 이번 주말에 오픈 소스 멘토링을 진행하게 되었다. 오픈 소스 멘토링을 참여하게 된 이유는 오픈 소스에 기여해보고자 하는 마음은 컸지만, 매번 두려워서 제대로 시작을 하지 못하고 있었다. 내가 이렇게 수정하는 것이 맞는 지, 이렇게 해도 되는 게 맞는 것인 지에 대한 확신히 없었기 때문이다.멘토링의 진행과정을 통해서, 오픈 소스에 기여하는 방법에 대해서 서술 해보도록 하겠다. 1. 기여하고 싶은 오픈 소스를 고르자. ( 처음이라면 , 친숙한 라이브러리 부터 도전 해보자 ). 멘토링에서 처음으로 한 것은 우선 기여하고 싶은 라이브러리를 고르는 것 이였다. 이번 멘토링을 통해서, 오픈소스에 기여해보는 경험을 무조건적으로 해보고 싶어서, 도전적인 라이브러리 보다는 현재 회사에서도 사용하고 있고, 많이 접해본 라이브러리들을 선택하게 됐다. 그러하여, 내가 선택했던 라이브러리는 material-ui 와 shadcn-ui 를 선택했다. 테스트 환경 구성 과 해당 코드를 분석하는 데 있어서, 해당 오픈 소스를 선택했던 것이 도움을 줬던 듯 하다.<ol start="2"><li>이슈를 선정하자- 이슈를 잘 선정한다면, 쉽게 오픈 소스에 기여를 할 수 있다. 우선, 이슈를 해결하려면 어떤 이슈인 지 파악하는 게 중요한데, 해당 이슈가 발생했던 현상에 대한 자세한 설명이 없다면, 우리는 어떤 에러이고, 어떤 것을 고쳐야하는 지 아예 감을 잡을 수 가 없다. 그렇다보니, 이슈에 자세한 설명이 있는 이슈를 선택하는 것이 매우 중요함을 느꼈다. -그렇다면, 나는 어떠한 이슈를 선택헀는 지 보려고 한다. 제가 선택했던 이슈는 다음과 같습니다. 선정했던 이슈 ( Dialog 가 전체화면인 경우에, 키보드를 통한 스크롤 이동이 동작하지 않음 ) ( <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/mui/material-ui/issues/42989">[material-ui][Dialog] Keyboard scrolling doesn't work in fullscreen mode #42989</a>) 해당 에러를 선택했던 가장 큰 이유는 두 개가 있었다. 해당 이슈를 작성한 사람이 해당 에러가 발생하는 상황을 코드 샌드박스로 구현을 해놔서 어떠한 에러인 지 쉽게 가늠할 수 있었기 때문이다. 뿐만 아니라, 메인 테이너 또한 해당 현상이 focus 가 정상적으로 작동했으면 , 일어나서는 안되는 버그라고 명시 했기 때문에, 해당 이슈에 도전하게 되었다.<ul><li>이슈를 선정하는 데 있어서 중요한 두가지가 존재한다.<ol><li>해당 이슈가 발생했던 현상이 자세히 설명되어 있는 이슈를 선택하는 것이 좋다.</li><li>메인테이너가 버그라고 선정한 이슈들을 선택하는 것이 좋다.</li></ol></li></ul></li></ol>3. 해당 이슈에 대해서, 코드를 디버깅 해보자처음 해당 에러를 접하고, 메인 테이너에 말에 따라, focus 가 모달에 정확히 들어가지 않았을 것이라고 생각하고, focus 만 제대로 하게 해준다면, 정상적으로 작동할 것으로 생각이 됐다. 그러하여, Dialog 가 풀 스크린 인 경우와 풀 스크린이지 않을 경우에 대해서 focus 가 다르게 들어가 있는 지를 먼저 확인하려고 진행했다.<pre spellcheck="false"><code class="language-javascript">console.log(document.activeElement);
// 현재 돔이 focus 하고 있는 Element를 리턴해준다.
// https://developer.mozilla.org/en-US/docs/Web/API/Document/activeElement</code></pre>해당 코드를 통해, 풀 스크린 인 경우와 풀스크린이지 않은 경우에서, 둘의 값을 비교해봤다. 그러나, 두 경우 모두 똑같은 곳을 바라보고 있었다. 그렇다면, focus 에서는 문제가 없음을 깨닫고, 우선, Dialog 라는 컴포넌트를 분석하기 시작했다. 해당 컴포넌트는 Modal 컴포넌트와 FocusTrap 컴포넌트를 통해서 구성이 되어 있었다. 모달을 띄웠을 때, focus 가 모달의 내용 쪽에 자동으로 잡히게 하는 로직이 FocusTrap 에 구성되어 있었다. 또한, useModal 에 키보드 이벤트를 제어하는 부분이 있어서, 해당 코드에 콘솔을 찍어봄을 통해서, target 이 되는 부분과, 화살표 방향들의 키가 정상적으로 작동하는 지, 또한, 디버깅을 통해, focus가 되고 있는 엘리먼트에 이벤트가 정상적으로 전파되고 있었는 지 확인을 했다. 그럼에도 불구하고, 키들도 모두 정상적으로 작동하고 있었고, 이벤트 또한 정상적으로 포커스 된 엘리먼트로 전파 되고 있었다.그럼에도 불구하고, 풀스크린일 때에만 , 키보드를 통한 스크롤이 작동하고 있지 않았다. 수 많은 고민을 통해, 그렇다면, 스크롤이라는 것이 아예 작동을 할 수 없는 상태인 것이 아닌 지 살펴볼 필요가 있었다. 그러하여, 확인해보니 ,

오픈소스 멘토링

React Native 는, 처음 발표된 지 벌써 6년이 넘었지만, 2024.11 현재까지 버전이 아직 0.76 에 그치고 있죠.버전이 아직도 1.0 에 이르지 못하고 있다는 것은, RN 이 아직 안정화 되지 못한 단계에 머무르고 있다는 의미이기도 하겠습니다.이 때문에, RN 의 개발방식은 아직까지도 뚜렷하게 정형화 되지 않고 있는 것 같습니다.공식 버전이