rubygems 상당히 괜찮은데, 현재 가장 아쉬운 부분은 1) 메타데이터 포맷이 통일되어 있지 않고, 2) 확장 모듈을 빌드하기 위한 추상화가 덜 되어 있다는 점입니다. Perl의 CPAN 처럼 메타데이터 포맷을 통일하고, 리파지터리를 비롯해서 체계적인 배포 시스템을 만들고, Python의 distutils가 가진 컴파일러 추상화 같은 부분을 잘 흡수하는 것이 현재의 과제일 것 같습니다.
그외 또 한가지 단점을 지적하자면 배포 시스템이 좀 엉망이라는 느낌입니다. 현재 gforge의 릴리스 시스템과 연동해서 gforge에 gem 파일을 올리면 알아서 배포가 되는데, 전혀 검증 장치가 없기 때문에 문제가 있는 gem이 배포될 가능성이 높습니다. gforge에서 해당 gem 파일을 지워도 gem 미러에는 그대로 남아있어서 완전히 제거가 안됩니다. 검증도 안된 gem 파일이 이렇게 마구 배포되면 문제가 있죠. -.-
단점만 얘기했는데, rubygems의 진가는 'gem up'도 있지만 버전 관리가 매우 유연하다는 점인 것 같습니다. 의존하는 라이브러리의 버전을 개발자가 통제할 수 있기 때문에 라이브러리의 버전이 올라가도 별로 걱정 없이 업그레이드를 할 수 있습니다. 이것은 새로운 버전이 보다 쉽고 빠르게 확산되는 데 도움이 되는 것 같습니다.
댓글
예전에 제 블로그에 rubygems에 대해 남긴 적이 있어서 소개합니다.
예전에 제 블로그에 rubygems에 대해 남긴 적이 있어서 소개합니다.
http://nohmad.sub-port.net/typo/2005/04/25/theres-gem-in-ruby
rubygems 상당히 괜찮은데, 현재 가장 아쉬운 부분은 1) 메타데이터 포맷이 통일되어 있지 않고, 2) 확장 모듈을 빌드하기 위한 추상화가 덜 되어 있다는 점입니다. Perl의 CPAN 처럼 메타데이터 포맷을 통일하고, 리파지터리를 비롯해서 체계적인 배포 시스템을 만들고, Python의 distutils가 가진 컴파일러 추상화 같은 부분을 잘 흡수하는 것이 현재의 과제일 것 같습니다.
그외 또 한가지 단점을 지적하자면 배포 시스템이 좀 엉망이라는 느낌입니다. 현재 gforge의 릴리스 시스템과 연동해서 gforge에 gem 파일을 올리면 알아서 배포가 되는데, 전혀 검증 장치가 없기 때문에 문제가 있는 gem이 배포될 가능성이 높습니다. gforge에서 해당 gem 파일을 지워도 gem 미러에는 그대로 남아있어서 완전히 제거가 안됩니다. 검증도 안된 gem 파일이 이렇게 마구 배포되면 문제가 있죠. -.-
단점만 얘기했는데, rubygems의 진가는 'gem up'도 있지만 버전 관리가 매우 유연하다는 점인 것 같습니다. 의존하는 라이브러리의 버전을 개발자가 통제할 수 있기 때문에 라이브러리의 버전이 올라가도 별로 걱정 없이 업그레이드를 할 수 있습니다. 이것은 새로운 버전이 보다 쉽고 빠르게 확산되는 데 도움이 되는 것 같습니다.
----
http://nohmad.tumblr.com/
Re: sudo gem update --system 너무 마음에 드는군요.
gentoo 를 사용하시면 가능합니다 =3=33
(다만 자바 관련된 것들은 대부분 라이센스등의 문제로 자동 다운로드가 가능하진 않더군요)
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
댓글 달기