Определиться с новыми библиотеками

[artbear]

Есть разные полезные методы, которые юзаются/будут юзаться не в одном скрипте.
Например, КопироватьДеревоФайлов
или получение пути программы из переменной среды Path
или метод для проверки минимально нужной версии oscript и выброс исключения

Поэтому предлагаю подобные методы также закидывать в библиотеку.

Вопросы - как назовем соответствующие разделы библиотеки (русский и английский варианты)
КопироватьДеревоФайлов просится в раздел ФайловыеОперации/Файлы/files

По другим упомянутым методам пока не знаю, куда поместить.

Жду мнений.

[artbear]

Также метод поиска последней версии 1С может пригодиться в разных скриптах.
Куда его положить?

[EvilBeaver]

получение пути программы из переменной среды Path

Вот это для чего?

Также метод поиска последней версии 1С может пригодиться в разных скриптах

V8Runner.ПолучитьПутьКПлатформе1С("8.3.6")

[nixel2007]

получение пути программы из переменной среды Path

Вот это для чего?

Я вот тоже сейчас подумал об этом... Ведь если бинарник лежит в Path, при запуске через КомандаСистемы() ему уже не нужен полный путь.
(Родилось из обсуждения к этому пулл-реквесту)

[dmpas]

Ведь если бинарник лежит в Path, при запуске...

А если это не бинарник и его требуется не запустить, а просмотреть?
К примеру, есть у меня в Path-е скрипт vit. Запустить я его могу просто командой vit, а посмотреть его содержимое только через cat $(which vit)

PS я не в теме, просто мимо пробегал

[artbear]

Также метод поиска последней версии 1С может пригодиться в разных скриптах
V8Runner.ПолучитьПутьКПлатформе1С("8.3.6")

Отлично, один вопрос снимается.

[artbear]

Ведь если бинарник лежит в Path, при запуске через КомандаСистемы() ему уже не нужен полный путь.
(Родилось из обсуждения к этому пулл-реквесту)

Да, меня также удивило код из обсуждения. Но там есть фишка в том, что бинарник может называться по-разному :) v8unpack и unpackv8. Это неудачное решение.

[artbear]

1. Куда закинем КопироватьДеревоФайлов ?
2. Метод получение пути программы из переменной среды Path полезен (навскидку)
   • для скриптов-установщиков,
   • для скриптов, в которых нужно проверить существование пути к программе. Ведь простой вызов "программа параметры ..." приведет к системному исключению, пользователю скрипта это может быть неудобно. Я говорю о повышению юзабельности.

[nixel2007]

Возможно не совсем в тему - подскажите, а пресловутый testrunner.os откуда-то из репо onescript где-то доступен как библиотека/отдельный описанный механизм? Или это вещь, присущая чисто репе onescript?
А то Артур сказал сегодня прогнать тесты, а я аж не сразу понял, чем их прогонять.

[artbear]

Кстати, хорошая мысль.
Нужно выделить тест-раннер как отдельное приложение/библиотеку

А вообще тест-раннер живет в основном репо 1скрипт на битбакете, это
небольшой порт нашего xUnitFor1C для oscript

ср, 4 Ноя 2015, 0:40, Nikita Gryzlov notifications@github.com:

Возможно не совсем в тему - подскажите, а пресловутый testrunner.os
откуда-то из репо onescript где-то доступен как библиотека/отдельный
описанный механизм? Или это вещь, присущая чисто репе onescript?
А то Артур сказал сегодня прогнать тесты, а я аж не сразу понял, чем их
прогонять.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[artbear]

Что будем делать со следующими вопросами?:

1. Куда закинем КопироватьДеревоФайлов ?
2. Метод получение пути программы из переменной среды Path полезен (навскидку)
   • для скриптов-установщиков,
   • для скриптов, в которых нужно проверить существование пути к программе. Ведь простой вызов "программа параметры ..." приведет к системному исключению, пользователю скрипта это может быть неудобно. Я говорю о повышению юзабельности.

[artbear]

А еще метод для проверки минимально нужной версии oscript и выброс исключения ?

[EvilBeaver]

Вся эта штука будет называться БСП? 😄
Имхо, надо перенять опыт. БСП выкристаллизовался из решений, используемых везде и повсеместно. Были выделены направления стандартизации (файлы, обновление иб, почта и т.д.)

С библиотеками oscript получилось так же. Рано или поздно код, требующий стандартизации, выявится. Пока предлагаю просто ждать и накапливать статистику. Станет понятно, какие функциональные блоки по каким библиотекам просятся.

[artbear]

@EvilBeaver Так я и написал уже несколько вариантов. когда понятно, что есть общий/дублированный в нескольких скриптах функционал
и желательно его объединить в библиотеку.

[EvilBeaver]

@artbear так я и не спорю. Я говорю о том, что несколько библиотек будет, по функциональному признаку разделенных. Пока я вижу 2 библиотеки: файловые операции и окружение (для версии Скрипта) Но в каждой - по одной функции, на библиотеку не тянет

[EvilBeaver]

@artbear, возвращаясь к этой issue - ты можешь уже сейчас создать либу, скажем file-utils и скидывать в нее все, что похоже на универсальные функции. Ну и по прочей функциональности тоже...

Если вопрос о фиксации небольшого набора "полезных" функций, то мне идея кажется опасной. Фиксируя что-либо в библиотеке со слишком общим названием, мы потом ничего из этого не переделаем. Тут, на самом деле, проблема сильно шире и нам нужен полноценный хаб пакетов, наподобие nuget или тех же хранилищ пакетов для Atom и Sublime. Т.е. начинать надо с потребностей:

• Есть у меня набор методов, которые я часто использую и хочу поделиться
• Я создаю свой пакет и публикую его в хабе
• Заинтересованные лица устанавливают его себе

Тогда, если пакет становится очень популярен, он входит в типовую поставку OneScript и поставляется в составе дистрибутива OneScript. Вообще, идея хранения всех пакетов внутри одного репо oscript-library она не сильно хорошая. И работать она будет только пока идет активное развитие пакетов и все они друг с другом связаны. Сейчас, доработка одного пакета часто приводит к доработке другого.

В итоге, я думаю, что репо oscript-library станет техническим хранилищем пакетов, которые входят в поставку OneScript. А все прочие пакеты будут разрабатываться отдельно и ставиться из хаба по усмотрению клиента.

[dmpas]

Можно закрыть, мне кажется.