| 11 Dec 2022 |
 GALLY | Aí você tem que escrever explicitamente, ~/my-scripts/bin/erase-pictures | 00:01:10 |
 @baduhai:matrix.org | Isso | 00:01:19 |
| GALLY | * Aí você tem que escrever explicitamente, ~/my-scripts/bin/erase-weekend-pictures | 00:01:22 |
| GALLY | Ou você inclui ~/my-scripts/bin/ no $PATH | 00:01:52 |
| @baduhai:matrix.org | Mas no nix não existe uma pasta especifica onde as bibliotecas estariam, acho q sei onde vc esta indo com a conversa, o q eu não sei exatamente é como lidar com isso | 00:03:25 |
| @baduhai:matrix.org | Entendo como o makeWrapper talvez me ajude, o problema é q o programa não foi escrito procurando o $PATH, e sim hard-codando o diretório onde cada distribuição coloca os cores | 00:05:14 |
| @baduhai:matrix.org | Meio tosco, mas é assim q o autor fez, pq muitas distribuições não expõem os cores, como se não esperassem nenhum programa alem do retroarch usar os cores do libretro | 00:06:35 |
| @baduhai:matrix.org | Por isso q eu acabei usando o patch q eu escrevi | 00:07:20 |
| @baduhai:matrix.org | Acho q o substituteInPlace tbm possa me ajudar, mas pelo o q eu entendi, como o retroarch é uma dependência opcional, o substituteInPlace só vai ser executado se o retroarch for instalado como dependência, fazendo com q se eu instalar o retroarch depois do emulationstation-de, o substituteInPlace nunca tenha executado, e os cores não serão encontrados | 00:11:50 |
| @baduhai:matrix.org | In reply to @baduhai:matrix.org
Acho q o substituteInPlace tbm possa me ajudar, mas pelo o q eu entendi, como o retroarch é uma dependência opcional, o substituteInPlace só vai ser executado se o retroarch for instalado como dependência, fazendo com q se eu instalar o retroarch depois do emulationstation-de, o substituteInPlace nunca tenha executado, e os cores não serão encontrados Meu raciocínio faz sentido, ou to completamente errado? | 00:12:14 |
 Lucas Eduardo | In reply to @baduhai:matrix.org
Meu raciocínio faz sentido, ou to completamente errado? Tá certo | 00:19:43 |
| Lucas Eduardo | BTW tu pode tentar patchear pra pegar as coisas de uma variável de ambiente e aí no makeWrapper passar o valor | 00:20:47 |
| @baduhai:matrix.org | In reply to @telegram_155706732:t2bot.io
BTW tu pode tentar patchear pra pegar as coisas de uma variável de ambiente e aí no makeWrapper passar o valor Boa ideia, vou testar, não sei se o programa vai respeitar a variável no arquivo q vai ser patcheado | 00:23:08 |
 Anderson Torres | In reply to @baduhai:matrix.org
Mas no nix não existe uma pasta especifica onde as bibliotecas estariam, acho q sei onde vc esta indo com a conversa, o q eu não sei exatamente é como lidar com isso Eu, ou melhor, um tanto de gente teve que enfrentar uma situação parecida com o MPV.
O MPV suporta scripts Lua, como se fosse um sistema de plugins.
Basicamente o pessoal criou uma derivação que junta todo mundo num mesmo "diretório" via symlinks, mais precisamente via symlinkJoin.
https://github.com/NixOS/nixpkgs/blob/7bbdd67dee01d12d9f12835f2de05dc0fcf4fb5c/pkgs/applications/video/mpv/wrapper.nix#L61
| 00:27:14 |
| Anderson Torres | Eu costumo usar esse código como guia para quando preciso de algo similar. | 00:27:35 |
| Anderson Torres | In reply to @baduhai:matrix.org
Entendo como o makeWrapper talvez me ajude, o problema é q o programa não foi escrito procurando o $PATH, e sim hard-codando o diretório onde cada distribuição coloca os cores Então isso é no nível do código-fonte em C?? | 00:28:32 |
| Lucas Eduardo | In reply to @anderson_torres:matrix.org
Então isso é no nível do código-fonte em C?? Em C é bem simples até patchear pra trocar uma string constante pra uma variável de ambiente | 00:31:14 |
| Lucas Eduardo | Vai ter lifetime do programa igual | 00:31:22 |
| Lucas Eduardo | Tem uma função getenv né | 00:31:35 |
| @baduhai:matrix.org | In reply to @anderson_torres:matrix.org
Então isso é no nível do código-fonte em C?? Mais ou menos, o código-fonte se refere a um arquivo XML onde tem a referencia de diretórios | 00:31:41 |
| Lucas Eduardo | In reply to @baduhai:matrix.org
Mais ou menos, o código-fonte se refere a um arquivo XML onde tem a referencia de diretórios Entao da pra fazer o esquema de variável de ambiente pra passar onde tá o XML e usa o nix pra gerar o XML | 00:32:48 |
| Anderson Torres | In reply to @baduhai:matrix.org
Mais ou menos, o código-fonte se refere a um arquivo XML onde tem a referencia de diretórios Ele "vira" binário depois?
Ou fica um tipo de configfile, que nem um, sei lá, /usr/share/emulationstation.conf da vida? | 00:32:57 |
| @baduhai:matrix.org | In reply to @anderson_torres:matrix.org
Ele "vira" binário depois?
Ou fica um tipo de configfile, que nem um, sei lá, /usr/share/emulationstation.conf da vida? Não, o arquivo XML pode ser editado depois da compilação, e o programa vai interpretar as diferenças novas | 00:33:44 |
| Anderson Torres | In reply to @telegram_155706732:t2bot.io
Entao da pra fazer o esquema de variável de ambiente pra passar onde tá o XML e usa o nix pra gerar o XML O problema é saber se isso é feito na hora de compilar ou na hora de usar. | 00:33:51 |
| @baduhai:matrix.org | É na hora de usar | 00:34:05 |
| Anderson Torres | Então é sussa - quer dizer, cê pode fazer um do zero se quisesse, né? | 00:34:48 |
| Anderson Torres | * Então é sussa - quer dizer, cê poderia fazer um do zero se quisesse, né? | 00:34:58 |
| @baduhai:matrix.org | É, tbm achei meio louco quando tava escrevendo o derivation | 00:35:20 |
| Anderson Torres | Então dá para fazer assim: cria um wrapper que junte o teu programa mais os cores, e nesse wrapper inclui esse arquivo devidamente modificado. | 00:36:39 |
| Anderson Torres | Dependendo do caso, dá para fazer o próprio Nix gerar esse arquivo. Mas na pior hipótese simplesmente usa um esquema de template. | 00:37:26 |
