mam_mol
mam_mol copied to clipboard
hyoo-ru
Лапша из репозиториев
На данный момент под крышкой hyoo-ru 65 репозиториев. Каждое приложение имеет свою репу, где название это её поддомен, что неконсистентно с шаблоном именования mam_{some}, который применяется в mam_lib, mam_mol, mam_hyoo.
Можно ли средствами mam сделать репозиторий со всеми приложениями $hyoo, и "подмешивать" в этот неймспейс модули из других репозиториев, например $hyoo_crowd? И стоит ли?
Также, часть приложений в mol/app являются редиректами на приложения под hyoo.ru. Зачем они нужны?
Я хочу понять, является ли текущее состояние дел правильным, и можно ли сделать лучше.
Мотивация такая: Несколько недель назад я пытался предложить локализации в приложения, но, видимо, удалил свои форки раньше времени и все пулреквесты схлопнулись. А иметь и поддерживать тьму форков не хочется.
Также, на мой взгляд, неконсистентные имена репозиториев и сплетение приложений, ухудшают исследуемость экосистемы.
На данный момент под крышкой hyoo-ru 65 репозиториев. Каждое приложение имеет свою репу, где название это её поддомен, что неконсистентно с шаблоном именования
mam_{some}, который применяется в mam_lib, mam_mol, mam_hyoo.
Я думаю лучше вообще отказаться от префикса mam_ и оставить lib, mol, hyoo.
Можно ли средствами mam сделать репозиторий со всеми приложениями $hyoo, и "подмешивать" в этот неймспейс модули из других репозиториев, например $hyoo_crowd? И стоит ли?
Сделать-то так не сложно и примерно так было с $mol_app, но десятки не связанных друг с другом приложений в одном репозитории - это плохо масштабируемое решение. Сейчас проект $hyoo демонстрирует возможности MAM по масштабированию разработки на множество команд, каждая из которых работает со своим репозиторием.
Также, часть приложений в mol/app являются редиректами на приложения под hyoo.ru. Зачем они нужны?
Собственно, это остатки от переезда ряда приложений из зоны "демок" в зону "самостоятельных продуктов". Редиректы оставлены, чтобы внешние ссылки на эти приложения выдавали не 404, а актуальный адрес. Возможно какие-то из них или даже все уже можно безболезненно удалить - это надо с каждым разбираться отдельно.
Я хочу понять, является ли текущее состояние дел правильным, и можно ли сделать лучше.
Экосистема постоянно эволюционирует, так что тут и там можно встретить атавизмы, так что везде есть что улучшить.
Несколько недель назад я пытался предложить локализации в приложения, но, видимо, удалил свои форки раньше времени и все пулреквесты схлопнулись. А иметь и поддерживать тьму форков не хочется.
Пулреквесты можно переоткрыть же. Вообще, предлагать патчи можно и через интерфейс гитхаба не создавая у себя форков.
Также, на мой взгляд, неконсистентные имена репозиториев и сплетение приложений, ухудшают исследуемость экосистемы.
Речь о том, чтобы переименовать имена вида sketch.hyoo.ru в hyoo_sketch? Да, это было бы логично. Хотя сейчас можно по имени домена понять где искать его код. С другой стороны, одно приложение может быть доступно и на разных доменах.
Тут есть ещё такой нюанс: в рамках организации hyoo-ru есть же не только MAM репозитории. И если всё именовать по mam-неймспейсам, то для них получается не останется места, ведь если их оставить, о это будет вводить в заблуждение.
Я думаю лучше вообще отказаться от префикса mam_ и оставить lib, mol, hyoo.
Например https://github.com/hyoo-ru/perf.js.hyoo.ru - он должен называться hyoo_js_perf но из-за того что автодеплой есть на гитхаб страницы надо называть по доменному имени. Причем не обязательно доменное имя будет соответствовать тому как внутри приложение называется только читая задом наперед (В этом примере оно соответствует - $hyoo_js_perf)
В mam_ префиксе есть плюс, я однозначно знаю что речь идет о компоненте mam экосистемы. Это наоборот упрощает просмотр реп и отфильтровывать от левых не под mam сделаные репы (если такие были б). Я б хотел иметь какой-то префикс, если не мам то что-то другое.
Не, на гитхаб пейджес ссылки получаются сейчас вида https://hyoo-ru.github.io/perf.js.hyoo.ru, так что ограничений на имена особо нет.
Ну вот hyoo_ и mol_ могут быть такими префиксами.
Не пользовался гитхабпейдж, не знал.
Тогда надо ответить на вопрос, надо давать информацию где лежать проект будет и что он требует mam (иначе все это в ридми надо описывать)
Думаю название ревы по типу mam_hyoo_js_perf лучше всего подходит.
Почему:
- Фильтрация реп, если все они будут содержат
mam_то легко отфильтровать именно проекты которые сделаны с mam подходом - Сортировка реп! Фактически будет показано древо проектов
- Кто "в теме", тот поймет куда клонить надо, даже не читая ридми (если он самодостаточен и все зависимости уже есть в meta.tree вне этого неймспейса)
note: mam когда-то может стать отдельным проектом (например переместив mol/build/ в mam/), тогда будет mam_mam, не очень красиво. Но я не знаю как по другому указать в имени что проект сделан "под" mam.
С другой стороны имя репы https://github.com/hyoo-ru/case.hyoo.ru говорит сразу что что есть сайт, я его копирую и могу открыть. Ибо ридми @nin-jin добавлять лениться :) Если его перейменовать в mam_hyoo_case то надо создать ридми файл и вставить туда ссылку на приложение. Что считаю также ок, ридми вставлять надо всегда, иначе выглядит не серьезно и сиротой репа, тем более зачастую в приложении нету описания о чем приложение вообще, юзер, должен разгадать квест по сути, но есть зачастую иконка на исходники-гитхаб, тут бы и ридми пригодился.
В общем я за единообразие, mam_ или подобный префикс для каждого проекта
В описании каждого репозитория так-то есть ссылка на сайт.
Ещё есть такой момент: Если именовать по неймспейсу, то разные инструменты могут использовать это соглашение для автоматизации рутины. Например, можно упростить meta.tree избавив от необходимости прописывать в нём каждый репозиторий, чтобы он мог автоматически выкачиваться.
Точкой входа для пользователя всё же является не репозиторий, а сайт, а на сайте уже есть ссылки на репы.
В описании каждого репозитория так-то есть ссылка на сайт.
Возможно, но я открыл первый попавшийся, и не нашел https://github.com/hyoo-ru/case.hyoo.ru
Ещё есть такой момент: Если именовать по неймспейсу, то разные инструменты могут использовать это соглашение для автоматизации рутины. Например, можно упростить meta.tree избавив от необходимости прописывать в нём каждый репозиторий, чтобы он мог автоматически выкачиваться.
Интересная идея, но я б лучше тулзу делал для обновления meta tree нежели запросы слать к гитхабу, что б не было вендор-лок на гитхаб. Гитхаб сегодня есть, а завтра заблокируют или умрет, и потом пиши тулзу под другой гит-хостера. А meta.tree прост, юзер знает какие еще есть репки в экосистеме пакета без использования тулзов а открыв файл редактором.
Я говорю не о вендор локе, а о такого рода записях:
pack_prefix git \https://github.com/hyoo-ru/hyoo_
About
Это и есть вендорлок, когда надо будет уехать с гитхаба, эта инфа потеряеться. Ссылку не жалко, ибо хостится на гитхабе, пропадет гитхаб, ссылка будет не актулальна, но описание пропадет. Лучше что б репа была самодостаточной.
pack_prefix git \https://github.com/hyoo-ru/hyoo_
В таком случае нельзя сказать что же доступно тебе, надо открывать ссылку, убирать перфикс, долго нудно. Изучению через исходники будет затруднительно, надо лазить на гитхаб. Я понимаю что плюс в том что не надо будет комитить регистрацию нового компонента/приложение.
Учитывая, что хостится у нас всё на github pages, то пропажа гитхаба сделает и ссылку нерабочей.