Lucas Nussbaum: в Debian с Ruby все нормально

Подтверждаю: все зашибись! 8-)

> the fact that many Ruby developers have a web development background and not a UNIX background is clearly one of the reasons why it is harder to deal with that community than with the Perl or Python communities. And it is also true that many Ruby developers are using Mac OS X on their development systems, and don’t feel very concerned by Linux distributions issues.

Вендузятники и педи^Wмакосятники. Конечно, им хочется, чтобы всё делалось привычно - через жо^W^Wвендовенько.

Да, не устанавливайте ruby в убунте из исходников http://www.linux.org.ru/forum/desktop/5289006?lastmod=1283340161435

o_O а что-то было не нормально?

Пишущие на рельсах съехали с катушек и хотели всё самое распоследнее и быстро быстро быстро! По крайней мере у меня сложилось такое ощущение :)

>всё делалось привычно - через жо^W^Wвендовенько.

а что виндузятного в 'sudo port upgrade ruby'?

>> всё делалось привычно - через жо^W^Wвендовенько.

а что виндузятного в 'sudo port upgrade ruby'?

Ты уверен, что говоришь о Дебиан или даже Linux?

я говорю про мак, если что

> я говорю про мак, если что

Это там, где в стандартной поставке нет общесистемного менеджера пакетов?

Для нормальной работы приходится ставить руби из исходников (у них даже RVM в пакетах нет), это типа нормально?

>Это там, где в стандартной поставке нет общесистемного менеджера пакетов?

macports ставится через инсталлятор буквально в три клика, а дальше - см. команду выше

> macports ставится через инсталлятор буквально в три клика

Эээ... и что?

а дальше - см. команду выше

Да что на нее смотреть? И в дебиане можно обновлять руби в обход стандартного пакетного менеджера. Или гордость макосника - в том, что, хотя жопс не дал ему пакетного менеджера. макосятник смог скачать macports?

>макосятник смог скачать macports?
прочитайте исходный пост про «вендовенько»

И в дебиане можно обновлять руби в обход стандартного пакетного менеджера.

в одну команду?

>> макосятник смог скачать macports?

прочитайте исходный пост про «вендовенько»

Мой пост? Там как раз и имелось в виду - в обход стандартных средств управления пакетами. Ну да, в отношении макоса не очень точно - там стандартных средств вообще нет.

И в дебиане можно обновлять руби в обход стандартного пакетного менеджера.

в одну команду?

Насколько я понял из поста - да. Но, в общем-то, мне пофиг в одну или несколько - это всё партизанщина, поскольку... см. выше.

>The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them.

сурово. Но он прав

мдааа... казалось бы, нельзя сделать моё мнение о руби ещё хуже. но мир ещё способен удивлять!

The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them.

Ничего себе пещерный век! Если бы Руби был исследовательским проектом или находился в состоянии альфы, как D2, то такое ещё можно было бы понять: сначала разрабатывем принципиальную возможность реализации, а потом уж переносим на разные архитектуры. Но языку уже 15 лет и его версия значится как 1.9, если я не ошибаюсь.

Товарищи, это позор!

Я правильно понимаю, что разработчики в апстриме не знают слова production?

> Ничего себе пещерный век! Если бы Руби был исследовательским проектом или находился в состоянии альфы, как D2, то такое ещё можно было бы понять

Не знаю как сейчас, раньше с Руби была та же ж"па - недопиленная документация, многие либы и т.д. С переносимостью видимо так же.

> Но языку уже 15 лет и его версия значится как 1.9, если я не ошибаюсь.

Разработчики увязли в трясине перфекционизма. «Мы сделаем такой п##датый язык, что никакой воинствующий эстет не докопается». Но по факту воз и ныне там. Хотя гонору...

Хотелось бы видеть актуальные версии gem'ов в дополнительном deb-репозитории. А то эта солянка в первое время, пока не разобрался, парила мозги.

Разработчики увязли в трясине перфекционизма. «Мы сделаем такой п##датый язык, что никакой воинствующий эстет не докопается». Но по факту воз и ныне там. Хотя гонору...

Приходится писать на Питоне и могу сказать, что переносимость там тоже не всегда блещет, особенно при работе с процессами. Но всё-таки подобного безобразия не наблюдается и близко.

Кстати, фанаты Руби почему-то очень любят ругать питонщиков и обвинять в ереси. Достаётся из за отступы, и за не вполне ООП подход, и за многое другое.

>Не знаю как сейчас, раньше с Руби была та же ж"па - недопиленная документация, многие либы и т.д. С переносимостью видимо так же.

С документацией на сам язык и ядро всё в порядке. А вот с новым Rails похуже: книг до сих пор нет даже на английском, туториалы (даже видео, мать их!) в сети покрывают одну и ту же тему «кто быстрее сделает блог: 5, 7 или 15 минут». Документации с примерами для либ я не встречал вообще.

Если не прав - дайте ссылку :)

>Кстати, фанаты Руби почему-то очень любят ругать питонщиков и обвинять в ереси. Достаётся из за отступы, и за не вполне ООП подход, и за многое другое.

А это «многое другое» обычно не обоснованно, как, например, более простая работа с регэкспами в Руби?

> более простая работа с регэкспами в Руби?

Весомое преимущество. У тебя программы состоят из работы с регэкспами?

Если бы ты посмотрел на код этого RVM, ты бы испугался и тут же перестал им пользоваться :}

>Весомое преимущество. У тебя программы состоят из работы с регэкспами?

Весомое, если по остальным пунктам Руби не сливает. Оба языка я не знаю, оценивать не возьмусь - лучше дождаться спецов или примеров.

Весомое преимущество. У тебя программы состоят из работы с регэкспами?

Весомое, если по остальным пунктам Руби не сливает. Оба языка я не знаю, оценивать не возьмусь - лучше дождаться спецов или примеров.

Руби 1.9 рассматривать не будем, т.к. его не только нет во многих дистрибутивах, но он несовместим с рельсами, многими старыми сторонними модулями и т.д. Более того, в 1.9.x регулярно ломают что-нибудь из работавшего в 1.9.x-1. Поэтому будем рассматривать стабильную ветку 1.8.

Питон тоже возьмём самый распространённый на сегодня: 2.6.

Итак, что я знаю из того, в чём Руби объективно хуже: 1) он медленнее до 3 раз, хотя обычно раза в 1,5; 2) стандартная библиотека существенно уже; 3) внешние модули менее совершенны, например, нет полноценного аналога numpy, scipy, matplotlib, причём numpy используется уже не только в научных и инженерных расчётах, но и во многих прикладных программах, даже wesnoth тащит его.

О регулярных выражениях ничего сказать не могу, но Perl там всё равно не победить.

> Lucas Nussbaum: в Debian с Ruby все нормально

Это тянет на новость?

>Руби 1.9 рассматривать не будем

он несовместим с рельсами

4.2. Rails 3 совместим.

wesnoth прикладная программа, ага :)

Тянет. Ещё вопросы?

Ruby — несерьёзный язык для школоты, не оценившей элегантную простоту Python и не осилившей более сложные языки. Я не поклонник Debian, но видно, что культура разработки рубильников настолько низка, что не удовлетворяет требованиям, логичным для цикла жизни дистрибутивов типа Debian. Неудивительно.

P.S. Из статьи следует, что после выхода squeeze на Руби вообще, скорее всего, положат.

P.P.S. В Python ценой двух строк кода регвыры можно компилировать в объекты. А вы давайте, в циклах каждый раз их создавайте. «Проще», ха.

>С документацией на сам язык и ядро всё в порядке.

Спасибо, я рыдал над этим перлом!!!

>более простая работа с регэкспами в Руби

Perl тебе в помощь. Вот где регэкспы...

ээ, а зачем?

>>Хотелось бы видеть актуальные версии gem'ов в дополнительном deb-репозитории. А то эта солянка в первое время, пока не разобрался, парила мозги.

если ты девелопишь под рельсы то просто ставь гемы в рельсовый деплой и не засоряй систему.

>Хотелось бы видеть актуальные версии gem'ов в дополнительном deb-репозитории. А то эта солянка в первое время, пока не разобрался, парила мозги

Так ты же на генте сидишь

Руби? Паночка еще не помэрла?

В Debian есть одна неприятная проблема. И с Ruby и с Python и с Perl.

Она не в самих языках - там все можно решить. Она в gem'ах, eggs'ах и CPAN modules'ах. Для упрощения буду называть это все модулями.

Не секрет, что любой разработчик хочет «вон тот модуль, и не ниже вон той версии». А этот модуль или не упакован или упакован, но не тот. И идет разработчик делать sudo {gem,easy_install,pip,cpan} install foobarbaz.

И вот тут начинается больно, потому что половина стоит через apt/dpkg, половина так, половина этак. Если еще на системе две версии ruby/python/perl (скажем, ruby 1.8.7 для «стабильно» и ruby 1.9.2 для «попробовать») то там начинается вообще бардак «это встало в /usr/lib/python2.5, а это в python-shared а это вообще в /usr/local, тьху». С python, по крайней мере, точно - и документации на то, как устроены python-support и python-central (которые решают задачи раскладывания через dpkg) в Debian нету. Я искал, и долго - в итоге, мне пришлось лезть в исходники, и все равно у меня так до сих пор и нету четкого понимания как же оно работает - уж как-то намудрено там все.

Вот почти красиво это сделали в Gentoo - есть средства, которые берут чужой модуль (gem, egg, cpan module) и делают из него ebuild. Очень удобно. А вот инструменты «{gem,egg,cpan}2deb» все умерли толком не родившись, потому что разработчики задолбались и ушли пользоваться rvm (с удобным gem bundles) и прочими pip, равно как и ставить все в $HOME/.local. И это печально.

Статью не читал, но без RVM'а пользоваться хреново. А с RVM'ом - удобное. Теперь обьясните, почему это плохо.

>Вот почти красиво это сделали в Gentoo - есть средства, которые берут чужой модуль (gem, egg, cpan module) и делают из него ebuild. Очень удобно.

Но разве это спасет от того, что модули окажутся несовместимыми между собой и даже с версией python, ruby и пр. А что делать сопровождающему? В Debian предпочли пакетировать некоторые модули и библиотеки, но лично у меня руки бы опустились, будь я сопровождающим этих пакетов. Одна библиотека заложится на фичи самой новой версии другой библиотеки, поставил самую новую версию — поломалась тогда другая программа.

Вы бы со своим дилетантским мнением не лезли бы. Рельса совместима с 1.9. Стабильным считается 1.9.2. Сравнивать заведомо проигрывающую по скорости версию с питоновской (когда там 2.6 быстрее 3), это <..>.

И собственно, я не понимаю, почему обязательно дублировать функционал rubygems и какую-то часть гемов паковать в дебы. Это же пиздец. А потом ноют, что мейнтейнить не могут. Собственно тут на лицо *дебиан головного мозга*, когда проблемы лежат на поверхности, а мейнтейнеры говорят *нет, у нас всё нормально* и тут же *мне это надоело, я всё бросаю*. Поведение школоты, право слово.

> В Debian есть одна неприятная проблема. И с Ruby и с Python и с Perl.

Эта проблема затрагивает не только Debian и Ruby/Python/Perl, а все дистрибутивы и любую программу позволяющую установку дополнительных модулей (TeX, Eclipse, Firefox, например).

Зелёный ты ещё, глупый совсем. Подрастёшь — поймёшь, что программы должны опираться на что-то одно, а когда программам для одной версии дистрибутива будет нужен десяток разных версий гемов, будет уже поздно.

> С python, по крайней мере, точно - и документации на то, как устроены python-support и python-central (которые решают задачи раскладывания через dpkg) в Debian нету. Я искал, и долго - в итоге, мне пришлось лезть ...

Ну, я аж прослезился и :

http://pkg-ruby.alioth.debian.org/ruby-policy.html/
http://www.debian.org/doc/packaging-manuals/python-policy/

> А вот с новым Rails похуже: книг до сих пор нет даже на английском

Beginning Rails 3 — Cloves Carneiro Jr., Rida Al Barazi — [2010, PDF, ENG]

Если не прав - дайте ссылку :)

http://rutracker.org/forum/index.php ;=)

зачем в один клик?

> http://www.debian.org/doc/packaging-manuals/python-policy/

Зря слезитесь, я это все видел первым же делом, спасибо. Это далеко не полное описание устройства всего околопитонового зоопарка в Debian.

В общем, всей описанной там информации мне не хватило для задачи «ввести в старую систему с python2.5 еще поддержку 2.7 (пакет я собрал, он работал), и чтобы с кучей eggs'ов и все было кошерно с apt/dpkg а не аки слакварь». Плюнул, поставил в /usr/local и окружил pip'овскими environment'ами.