АБ
Тогда просто
nix shell github:you/softwarenix run -f https://.../.../master.tar.gz -c твоясофотинушка, например.Size: a a a
2020 May 30
R
Потом это можно просто
а зависимости из nixpkgs и вот этого всего, что с ними будет?
АБ
а зависимости из nixpkgs и вот этого всего, что с ними будет?
В зависимости от того, как напишешь
d
Тогда просто
nix shell github:you/softwareТеперь у нас есть nix-shell, nix shell, nix run АСТАНАВИТЕСЬ
АБ
Можно запинить nixpkgs в твоей репе, например nivом или просто
fetchTarballАБ
Можно использовать
import <nixpkgs> {}АБ
Теперь у нас есть nix-shell, nix shell, nix run АСТАНАВИТЕСЬ
nix run уже про другое теперь )d
а зависимости из nixpkgs и вот этого всего, что с ними будет?
R
nix run уже про другое теперь )то есть не сработает то что выше написали?
АБ
то есть не сработает то что выше написали?
Пока что сработает
АБ
В 2.4 уже нет
SM
Теперь у нас есть nix-shell, nix shell, nix run АСТАНАВИТЕСЬ
А ещё
nix dev-shell!АБ
Обычно для питоноштук делают два пакета -- утилита и библиотека
АБ
Но можно и один пакет с несколькими outputs
d
а у меня в одном проектике утилита на питоне и файл-библиотека чтобы её пользователь подключал к себе в проект, это норм в одном пакете держать?
Я бы не задумывался об этом до тех пор, пока эта файл-библиотека кем-то действительно будет использоваться.
АБ
ooff
R
Я бы не задумывался об этом до тех пор, пока эта файл-библиотека кем-то действительно будет использоваться.
так удобство использования и установки напрямую влияет на вероятность что будет использоваться