Sunday, March 12, 2023
dev@conference.yunohost.org
March
Mon Tue Wed Thu Fri Sat Sun
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 19
20
21
22
23
24
25
26
27
28
29
30
31
   
             

[00:00:46] <Yunohost Git/Infra notifications> [YunoHost documentation] [🔴 Down] Request failed with status code 500
[00:01:44] <Yunohost Git/Infra notifications> [YunoHost documentation] [✅ Up] 200 - OK
[12:33:05] <Salamandar> > <@Alekswag:matrix.org> <whisper>any opinion regarding https://github.com/YunoHost/yunohost/pull/1627 ? 👀</whisper>

Ah i commented on it too late
[12:34:52] <Salamandar> > <@Alekswag:matrix.org> does it really reduces the overhead ? I don't have so much experience with node but to me it sounds like the dependency-tree is always super-accurate on what version to use and you end up duplicating stuff anyway because one app requires foobar version 1.3.4 and another one requires version 1.3.5.1

That makes me ask another question : Could apps provide a "cache" directory to prevent re-building stuff on upgrade ? (I'm thinking of python venv, npm build, cargo packages, etc)
[12:35:29] <Salamandar> Cache directories could be all deleted yunohost-wide by admin maybe. Maybe also put in a custom location.
[12:35:37] <Salamandar> (outside of /var/www)
[12:53:04] <Aleks (he/him/il/lui)> Eeeh yeah but do you mean there's for example some option in pip install that would implement such thing ?
[13:06:36] <Salamandar> i don't know for pip
[13:06:40] <Salamandar> but for npm and cargo, that's almost certain
[13:07:13] <Salamandar> or maybe a "build" directory more than a "cache" directory, idk
[19:54:10] <Bram[m]> pipx use a shared library mecanism but it's only for programs that are supposed to be used system wide with the CLI like "youtube-dl"
[20:02:15] <Yunohost Git/Infra notifications> [YunoHost demo] [🔴 Down] Request failed with status code 502
[20:03:42] <Bram[m]> I can't find another tool that does the same thing than pipx :<
[20:07:18] <Yunohost Git/Infra notifications> [YunoHost demo] [✅ Up] 200 - OK