Делаю копию проекта и работаю уже с ней. В предыдущей итерации описываю в doc-файле, что там реализовано, какие возникли проблемы и что собираюсь делать дальше <...> Если возникает «затык», что бывает регулярно, просто возвращаюсь к предыдущей, рабочей версии проекта и начинаю все заново.
Ну то есть я правильно понимаю, что вместо нормального контроля версий, все держится на собственной памяти и директориях вида "Проект", "Проект (1)", "Проект (2)" и т.д.?
устанавливает больше инструментов — очевидный минус, я не хочу, чтобы мне кто-то зачем-то устанавливал больше каких-то там еще инструментов
Максимально странный поинт, типа - что плохого, что в регистри mise больше тулинга, который можно установить?
поддержка переменных окружения — три раза нет, ну может быть, иногда удобно, хотя для этого тоже есть миллион инструментов;
Ну вот встречный вопрос - а зачем мне мучаться с "миллионом инструментов"?
неангажированный вывод для тех кто сюда забредет: если у вас уже asdf, вам вряд ли понравится, если нет — лучше, наверное, начинать прямо с mise
Пересел с asdf спустя год использования на mise еще во времена, когда mise был rtx - вообще ни о чем не жалею: была постоянная боль с asdf+make+direnv+доморощенные shell-хуки - все заменилось одним, которые сразу работает нормально.
Ни разу в жизни не видел того, кого бы устраивал makefile, везде где его встречал это был write-once костыль, который и открывать то было стремно, не говоря уже о добавлении чего-то нового.
Вообще обычно для подобных случаев использутеся связка из:
require-dev блока в композере, npm и т.п., чтобы ставить зависимости нужные для разработки только если они нужны
Речь о разных зависимостях - mise не заменяет условный composer.json или package.json и не управляет зависимостями библиотек в проекте. Но и composer при наличии в require "php": ">=7.4" нужную версию php не установит, в отличии от mise. Более того - имея несколько проектов с разными версиями того же php, mise автоматически подставляет в PATH нужную, снимая всю головную боль с update-alternatives и прочими приседаниями с тем "а какая версия php/node/python/ruby/etc. у меня сейчас". (Хотя в наше время и без контейнера это уже анахронизм)
.env все же более универсальный механизм и позволяет не хранить все секреты в одном месте
И он тоже поддерживается mise. Если пользовались direnv - это и его замена в том числе.
Что касается разъезжающихся версий у разрабов - если человек по каким-то причинам не обновляет инструментарий, ему утилиты не помогут.
Это +\- работает если разработчик один и проектов или немного или они все однотипные. В крупных проектах ситуация, когда версия языка отстала от актуальной, хорошо если не на мажорную (как часто с php), а хотя бы на 2-3 минорных, встречается в примерно 90% случаях, а сам процесс обновления - тот еще техдолг.
Но может ваша утилита и взлетит
Давненько уже взлетела, как и сама концепция - достаточно глянуть и что альтернативы появились - aqua, vfox, и что "родоначальник" asdf из набора bash-скриптов переписался полностью на go
питоновский uv вон набирает популярность, хотя его смысл вообще мне не понятен.
pyenv, pip, pipenv, virtualenv, poetry - ни о чем не говорят? Если да - вы скорее всего не работали над крупными проектами и/или в крупных компаниях
Сам люблю mise всей душой, еще со времени когда он назывался rtx, и делал пару контрибьютов в его регистри, но статья слабо продающая, что видно в комментах. Не хватает прям практического примера, что мол "вот у нас проект на такой-то python, в нем и makefile, и .python-version, и .env, и requirements.txt, а вот так mise во все это интегрируется практически нативно, но еще больше фичей можно получить если взять mise.toml".
Ага, он бы еще сказал "листать рилсы 16 часов в день это не зависимость, это - дисциплина".
Я не знаю насколько формализована эта проблема, зависимости от источников быстрого дофамина и эндорфина, но даже если "еще нет", то скоро точно думаю будет.
Да, все так. Грустно просто от всего этого, что люди в целом склонны быстро навешивать какие-либо ярлыки и держатся потом за них до последнего, но что поделать - жизнь такова, какова она есть, и больше — никакова
Оправдываться? А судьи кто? Если человек провел для себя такую черту "все кто работает в N - плохие" - ради бога, его право, только не надо другим свою позицию пропихивать апеллируя ad hitlerum при несогласии.
Повторяю - докопаться можно до кого угодно по поводу чего угодно.
Ну за себя могу сказать (работал в ВК, но не над максом) - плохо ощущал. Как и в любой другой крупной компании - всем кто выше тебя плевать что ты там думаешь и чувствуешь, только тут еще и извне ты для всех плохой потому что там работаешь независимо от того, в чем твоя работа заключается.
Таким подходом можно вообще что угодно оправдать и ровно также в чем угодно обвинить - в этом и был мой поинт, что применяю такую ментальную гимнастику можно прийти к чему угодно - поэтому такие обобщения это, имхо, заведомо проигрышная стратегия если цель реально разобраться, а не просто выпустить пар в интернетах
Ну то есть я правильно понимаю, что вместо нормального контроля версий, все держится на собственной памяти и директориях вида "Проект", "Проект (1)", "Проект (2)" и т.д.?
А что тогда используете для версионирования и/или обеспечения переносимости своих пет-проектов если не гит?
ИМХО, вообще лучше snap не пользоваться когда есть flatpak
https://asahilinux.org/
Оно не только открыто, но и воспроизводится до сих пор
Максимально странный поинт, типа - что плохого, что в регистри mise больше тулинга, который можно установить?
Ну вот встречный вопрос - а зачем мне мучаться с "миллионом инструментов"?
Пересел с asdf спустя год использования на mise еще во времена, когда mise был rtx - вообще ни о чем не жалею: была постоянная боль с asdf+make+direnv+доморощенные shell-хуки - все заменилось одним, которые сразу работает нормально.
Ни разу в жизни не видел того, кого бы устраивал makefile, везде где его встречал это был write-once костыль, который и открывать то было стремно, не говоря уже о добавлении чего-то нового.
Речь о разных зависимостях - mise не заменяет условный composer.json или package.json и не управляет зависимостями библиотек в проекте. Но и composer при наличии в require
"php": ">=7.4"нужную версию php не установит, в отличии от mise. Более того - имея несколько проектов с разными версиями того же php, mise автоматически подставляет в PATH нужную, снимая всю головную боль с update-alternatives и прочими приседаниями с тем "а какая версия php/node/python/ruby/etc. у меня сейчас". (Хотя в наше время и без контейнера это уже анахронизм)И он тоже поддерживается mise. Если пользовались direnv - это и его замена в том числе.
Это +\- работает если разработчик один и проектов или немного или они все однотипные. В крупных проектах ситуация, когда версия языка отстала от актуальной, хорошо если не на мажорную (как часто с php), а хотя бы на 2-3 минорных, встречается в примерно 90% случаях, а сам процесс обновления - тот еще техдолг.
Давненько уже взлетела, как и сама концепция - достаточно глянуть и что альтернативы появились - aqua, vfox, и что "родоначальник" asdf из набора bash-скриптов переписался полностью на go
pyenv, pip, pipenv, virtualenv, poetry - ни о чем не говорят? Если да - вы скорее всего не работали над крупными проектами и/или в крупных компаниях
Сам люблю mise всей душой, еще со времени когда он назывался rtx, и делал пару контрибьютов в его регистри, но статья слабо продающая, что видно в комментах. Не хватает прям практического примера, что мол "вот у нас проект на такой-то python, в нем и makefile, и .python-version, и .env, и requirements.txt, а вот так mise во все это интегрируется практически нативно, но еще больше фичей можно получить если взять mise.toml".
Например эта проблема taskfile в mise сразу работала
нейросетевой
С учетом нынешнего состояния ubisoft, возможно и получилось бы выкупить права (хотя б только на 5е), но другой вопрос - кто бы стал выкупать?
Peace sells, but who's buying
Ага, он бы еще сказал "листать рилсы 16 часов в день это не зависимость, это - дисциплина".
Я не знаю насколько формализована эта проблема, зависимости от источников быстрого дофамина и эндорфина, но даже если "еще нет", то скоро точно думаю будет.
Какой стек если не секрет? и сколько лет опыта?, а то в "150 - полоток" с трудом верится
Все время в голове идея "бросить все и уйти чинить мотоциклы", но это мысль из категории "в каждой шутке есть доля шутки"
Похожая история - в марте 25го ушел - до сих пор без работы. И вот только решился искать, а рынок вообще уже не радует.
Да, все так. Грустно просто от всего этого, что люди в целом склонны быстро навешивать какие-либо ярлыки и держатся потом за них до последнего, но что поделать - жизнь такова, какова она есть, и больше — никакова
Оправдываться? А судьи кто? Если человек провел для себя такую черту "все кто работает в N - плохие" - ради бога, его право, только не надо другим свою позицию пропихивать апеллируя ad hitlerum при несогласии.
Повторяю - докопаться можно до кого угодно по поводу чего угодно.
Ну за себя могу сказать (работал в ВК, но не над максом) - плохо ощущал. Как и в любой другой крупной компании - всем кто выше тебя плевать что ты там думаешь и чувствуешь, только тут еще и извне ты для всех плохой потому что там работаешь независимо от того, в чем твоя работа заключается.
Таким подходом можно вообще что угодно оправдать и ровно также в чем угодно обвинить - в этом и был мой поинт, что применяю такую ментальную гимнастику можно прийти к чему угодно - поэтому такие обобщения это, имхо, заведомо проигрышная стратегия если цель реально разобраться, а не просто выпустить пар в интернетах