Пакеты кода для повторного использования

[EvilBeaver]

Originally reported by: EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver)

---

Реализовать функционал наподобие bundles или gems. Код, предназначенный для повторного использования устанавливается куда-то в системе. В скрипте пишем:

#Использовать "json"
#Использовать "УправлениеКонфигуратором"
#Использовать "http"

УправлениеКонфигуратором.ВыгрузитьКонфигурациюВфайл("C:\1cv8.cf");
JSON.ЗаписатьJSON(Новый Структура("А,Б,В",1,2,3));
// Класс HttpЗапрос из пакета "http"
ЗапросКСерверу = Новый HttpЗапрос();

При этом пакетами могут быть как скрипты, так и .NET библиотеки dll.

---

• Bitbucket: https://bitbucket.org/EvilBeaver/1script/issue/89

[EvilBeaver]

Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):

---

Реализовано подключение пакетов и внешний скрипт-загрузчик. Остальное в рамках других подзадач.

[EvilBeaver]

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

---

Делается почти просто, но с магией.

Когда ты указываешь что у тебя в пакете есть запускаемый файл, ruby gem делает автоматически над над ним обертку запуска sh и bat и кладет рядом с самим ruby.exe в каталог bin

[EvilBeaver]

Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):

---

@allustin ну в Линуксе это решается применением shebang (по твоей ссылке он тоже используется) В результате имеем красивую семантику запуска. В винде это может быть что-то вроде ярлыка на установленный executable. Короче, есть тыща способов это сделать штатными средствами, без введения странного ключа "--bin" который, по сути должен лишь переопределить каталог расположения запускаемого "библиотечного" executable.

Кстати, cucumber стартует из командной строки windows просто по имени, хотя сам является ruby скриптом:

cucumber <аргументы>

Как у них там это сделано?

[EvilBeaver]

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

---

Да нет это я плохо написал:

попробую по другому - в пакете у меня могут быть не только модули подключаемые как библиотеки, но и запускаемые файлы.

Это фактически аналог Executable http://robdodson.me/how-to-write-a-command-line-ruby-gem/ из ruby

[EvilBeaver]

Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):

---

@allustin что-то я не понял: как это "не только, как библиотеки, но как запускаемые файлы"? А чем скрипт и ряд модулей к нему это не "запускаемый файл"? Или я не догоняю чего-то?

[EvilBeaver]

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

---

По фидбеку. Хотел написать длинно (как в том документе по мозговому штурму), но пока решил глобальности зафиксировать в 2.0

Но на самом деле - для начала функционала достаточно.

Единственное чего не хватает сразу с начала иметь возможно отдельной строки запуска (примерно)

#!bash
oscript --bin v8runner <дальше параметры>

То есть кейс следующий:

" Как разработчик я хочу

• Чтобы мои библиотеки были доступны не только как библиотеки, но и как запускаемые файлы из каталога установки oscript "

[EvilBeaver]

Original comment by artbear (Bitbucket: artbear, GitHub: artbear):

---

Да, хорошо получилось.

[EvilBeaver]

Original comment by Sergey Batanov (Bitbucket: dmpas, GitHub: dmpas):

---

>> Ключевое слово импорта: #Использовать <имя>
   Согласен.
>> Если <имя> указано в кавычках, то интерпретируется, как путь к каталогу.
  Согласен.
>> Если <имя> указано без кавычек, то воспринимается, как некое имя установленного пакета (по факту, это тоже имя каталога, только относительно файла oscript.exe)
    Согласен, но... Даёшь пространства имён!
>> Библиотека - это каталог.
    Согласен. Хотя архивчик (zip, opk) тоже бы пригодился.
>> Если в папке, где установлен oscript есть файл package-loader.os, то каталог библиотеки интерпретируется алгоритмом, заданным в этом скрипте package-loader.os
>> Если package-loader.os отсутствует, то все содержимое каталога библиотеки подгружается, как общие модули с именами, как у исходных файлов.
   Согласен.

Думаю, такой подход в целом приживётся.

[EvilBeaver]

Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):

---

Коллеги, по библиотекам:

1. Ключевое слово импорта: #Использовать <имя>
2. Если <имя> указано в кавычках, то интерпретируется, как путь к каталогу.
3. Если <имя> указано без кавычек, то воспринимается, как некое имя установленного пакета (по факту, это тоже имя каталога, только относительно файла oscript.exe)
4. Библиотека - это каталог.
5. Если в папке, где установлен oscript есть файл package-loader.os, то каталог библиотеки интерпретируется алгоритмом, заданным в этом скрипте package-loader.os
6. Если package-loader.os отсутствует, то все содержимое каталога библиотеки подгружается, как общие модули с именами, как у исходных файлов.
7. Сейчас в дистрибутив oscript.zip включен пример файла package-loader.os, в котором прописан примерный алгоритм чтения библиотеки.

Таким образом, знание о конкретном устройстве библиотеки вынесено из движка на уровень "загрузчика". Это позволит более гибко экспериментировать с наиболее удобной структурой библиотеки. Когда формат библиотеки устаканится, его можно прописать уже и в движке.

Дайте фидбек, что-ли :)

[EvilBeaver]

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

---

возможная задача на первую библиотеку #116

[EvilBeaver]

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

---

Так мы и до пакетного менеджера дойдем. Причем я серьёзно.

@Shenja предлагал смотреть в сторону npm https://docs.npmjs.com/