Comments 47
>на Python
>не только на Mac
и это действительно неожиданно
>не только на Mac
и это действительно неожиданно
:)
Ну, скажем, если бы он был на Руби, как часто делают фанаты гитхаба, было бы уже не так удобно, хотя и тоже кроссплатформенно.
Ну, скажем, если бы он был на Руби, как часто делают фанаты гитхаба, было бы уже не так удобно, хотя и тоже кроссплатформенно.
А в чем разница? Что-то тот, что тот есть под основные платформы и не составляет труда их установить.
В руби неудобные зависимости от версий gem'ов. То есть, если разворачивается сложное приложение, например, gitorious, то может получиться, что требуется установить какой-нибудь старый пакет. Различия между версиями, опять же, менее очевидны. Т.е., если для питона зависимость может быть от второй циферки в версии, то в руби уже от третьей.
Руби нравится мне как язык, но как экосистема для разработки он пока не очень мне подходит. Хотя отдельные штуки на нём мне очень нравятся, тот же Jekyll, например.
Руби нравится мне как язык, но как экосистема для разработки он пока не очень мне подходит. Хотя отдельные штуки на нём мне очень нравятся, тот же Jekyll, например.
Да, gitorious мы долго побеждали.
Пришлось перебирать различные варианты версий ruby и используемых gemов. Вообще на поток ruby поставить довольно тяжело, настройка сложного приложения может превратиться в долгий увлекательный процесс. В репе той же убунты все пакеты и джемы морально устаревшие, приходится много делать и ставить вручную.
Пришлось перебирать различные варианты версий ruby и используемых gemов. Вообще на поток ruby поставить довольно тяжело, настройка сложного приложения может превратиться в долгий увлекательный процесс. В репе той же убунты все пакеты и джемы морально устаревшие, приходится много делать и ставить вручную.
По-моему, вы описываете проблемы отдельных приложений, а не руби в целом.
Как в ruby gems, так и в bundler вы можете указать любые зависимости.
Как в ruby gems, так и в bundler вы можете указать любые зависимости.
Это я понимаю. А как правильно установить два гема, например, версии 0.9.9 и 1.0.1, чтобы выбирался правильный? Что-то такое было в gitorious с geoip.
А как вы себе представляете одновременное использование двух джемов? Если у вас два одинаковых джема, значит у вас одновременно два одинаковых класса. Конечно, так быть не может. Тут либо нужно обернуть во что-то один из классов, либо попытаться решить эту проблему ещё как-то, например попросить авторов одного из пакетов обновить зависимости.
А вот npm для Node.js вполне спокойно умеет установливать сразу нескольок версий пакета и подключать нужные в зависимости от зависимости текущенго приложения. Да что уж тут говорить, разделённый библиотеки в *nix могут быть установлдены сразу нескольких версий.
Руби это тоже может. Я говорю о том, что нельзя в одном приложении в одно время использовать две разные версии одной библиотеки.
Почему нет? если разные зависимости приложения могут в свою очередь зависеть от разных версий какой-то одной библиотеки, то что должно мешать разработчику использовать две версии одной бибилотеки напрямую в приложении? Собственно, npm в Node.js может и это.
Приведи, пожалуйста, пример кода.
В руби это нельзя сделать потому что две разные версии одной библиотеки будут иметь одно и тоже имя класса.
В руби это нельзя сделать потому что две разные версии одной библиотеки будут иметь одно и тоже имя класса.
Выглядит это примерно так:
В целом это заслуга JavaScript, что такое можно провернуть не упираясь в ограничения вроде единственности имени класса. В данном случае как такового класса нет.
// Get some API module in 3.1 version
var api3 = require('someapi@3.1');
// Work with 3.1 API
api3.get(params, callback);
// Get some API module in 2.3.8 version
var api2 = require('someapi@2.3.8');
// Work with 2.3.8 API
api3.get(params, callback);
В целом это заслуга JavaScript, что такое можно провернуть не упираясь в ограничения вроде единственности имени класса. В данном случае как такового класса нет.
Это-то понятно. Вам не показалось, что само по себе желание использовать две версии одной библиотеки разом странным?
Речь идёт о уже готовых проектах которые нужно использовать совместно и которые требуют двух разных версий одной библиотеки.
Речь идёт о уже готовых проектах которые нужно использовать совместно и которые требуют двух разных версий одной библиотеки.
bundler вам на что?
Если в одно приложении нужны две разные версии одной библиотеки, то bundler не поможет.
тогда уже ничего не поможет :)
В том то и дело. И я сомневаюсь что в python можно иметь библиотеку одновременно двух разных версий. Не понятно, почему автор выставляет это как недостаток руби.
Не в одно приложение, а в разные. Иногда не видятся гемы, хотя они есть, или не устанавливаются.
тут поможет rmv и его гемсеты
Спасибо за подсказку, понял, что делать дальше )
не за что. я еще и опечаться в 3-х буквах умудрился. речь об rvm, конечно же
тут как раз bundler решает, см Gemfile.lock
bundler вам в помощь
Прямо ирония судьбы. Почему бы тогда не дойти до логического завершения и не использовать hg
Простите, а чем это лучше банальных .cmd/.sh выполняющиъ эти функции?!
таскать червя ради пары команд по очереди — бредятина.
таскать червя ради пары команд по очереди — бредятина.
я бы сказал даже alias/function
В общем, так оно и есть, только скрипты на питоне, а не на шелле.
как на счет поделиться с нами своими .cmd/.sh, выполняющими эти функции?
Я не знаю что делают вышеуказанные, из описаний выходит вот что они делают (пишу так, чтоб можно было в bash функцию положить):
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.
Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.
Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop
UFO just landed and posted this here
Здесь могу добавить, что аналогичные алиасы можно задавать в ~/.gitconfig:
Соответственно, вызывать нужно git [st|co|pr|...].
[alias]
st = status
pr = pull --rebase
co = checkout
Соответственно, вызывать нужно git [st|co|pr|...].
это не одно и тоже в ~/.gitconfig сокращения для git комманд,
в ~/.profile или в ~/.bashrc – сокращения для вызовов git с параметрами, т.е. так вы можете весь Legit в aliasы унести.
в ~/.profile или в ~/.bashrc – сокращения для вызовов git с параметрами, т.е. так вы можете весь Legit в aliasы унести.
Не совсем сокращения, можно и команды писать, например, вот строчка из моего .gitconfig
Хранить такие команды в конфиге гита удобнее, если разработка идет на нескольких машинах с зоопарком шелов (bash, zsh etc), просто синхронизировав ~/.gitconfig
Можноизвращаться вызывать и чисто системные утилиты:
или для пуристов:
Понятно, что системные алиасы, не имеющее отношения к гиту хранить в гитконфиге странно, но мало ли.
По алиасам есть хорошая страничка на вики: git.wiki.kernel.org/index.php/Aliases
[alias]
...
rmd = rm $(git ls-files --deleted)Хранить такие команды в конфиге гита удобнее, если разработка идет на нескольких машинах с зоопарком шелов (bash, zsh etc), просто синхронизировав ~/.gitconfig
Можно
qq = !echo "HELLO"или для пуристов:
qq = !sh -c 'echo "HELLO"'Понятно, что системные алиасы, не имеющее отношения к гиту хранить в гитконфиге странно, но мало ли.
По алиасам есть хорошая страничка на вики: git.wiki.kernel.org/index.php/Aliases
а еще есть волшебный git flow
Sign up to leave a comment.
Legit: sexy git CLI