| 15 Jul 2021 |
 dom96#7486 | It's fair to discuss them | 18:48:02 |
| dom96#7486 | Let's forget how we would achieve this for now. let's assume that we have a magical server that always gives us the same package when we ask it for pkgFoo v0.1.0 | 18:48:49 |
| dom96#7486 | Can we make do with just MVS then? | 18:49:08 |
 arnetheduck#9853 | are you asking if MVS is deterministic for deterministic inputs? I'd assume so, yes | 18:49:59 |
| arnetheduck#9853 | but then you're still not making statements about MVS - you're making statements about the magical server - MVS is not relevant to the problem that lock files solve | 18:54:51 |
| arnetheduck#9853 | beyond being "stable" | 18:55:10 |
| arnetheduck#9853 | of course, you can start arguing semantics and meanings of the word, which this discussion sounds like | 18:55:39 |
| dom96#7486 | No, it is, because in MVS >= 0.1.0 will always give you 0.1.0, without MVS you might get any version that's greater than 0.1.0 | 18:55:39 |
| dom96#7486 | * No, it is, because in MVS >= 0.1.0 will always give you 0.1.0, without MVS you might get any version that's greater than or equal to 0.1.0 | 18:55:46 |
| arnetheduck#9853 | I don't know how to put this in another way: lock files solve a different problem - you can't solve the problem lock files solve with any version selection algorithm | 18:56:32 |
| dom96#7486 | Argh, discussing this over text is tough. I think we should get a VC at some point 😉
But let me try again. | 19:01:37 |
| dom96#7486 | At the simplest level, a lock file is just:
* A list of unique URLs we depend on that doesn't change
* with a hash for each URL that ensures whatever source code we get doesn't change at that URL.
I posit that MVS will always give the same list of URLs for the same requirements list (i.e. satisfying the first point).
As for the second point: yes, you need a hash to verify that the data you get remains the same (and this is the perfect kind of guarantee unless we get a hash collision). But if we are okay with trusting the server then we don't need lock files. | 19:04:49 |
| dom96#7486 | * At the simplest level, a lock file is just:
* A list of unique URLs we depend on that doesn't change
* with a hash for each URL that ensures whatever source code we get doesn't change at that URL.
I posit that MVS will always give the same list of URLs for the same requirements list (i.e. satisfying the first point).
As for the second point: yes, you need a hash to verify that the data you get remains the same (and this is the perfect, mathematical kind of guarantee. Unless we get a hash collision). But if we are okay with trusting the server then we don't need lock files. | 19:05:06 |
 haxscramper#4368 | We can't ensure we trust random URLs on GitHub | 19:05:40 |
| dom96#7486 | Indeed, but there are things we can trust (for example our own central code repository that we control) | 19:06:19 |
| haxscramper#4368 | That doesn't exist yet | 19:07:05 |
| dom96#7486 | ... yes, I know. Please, just focus on the point of this discussion | 19:07:25 |
| dom96#7486 | There are many disadvantages to a central code repo we control too of course | 19:07:42 |
| dom96#7486 | I just want to focus on whether MVS would be enough in that instance | 19:08:19 |
| haxscramper#4368 | Assuming every single package in nim have to be installed via this repository and we get rid of support for URLs in requirements, and this repository itself is not subject to changes (I personally did re-tag my package versions several times), then I believe MVS seems like a solution | 19:10:48 |
| haxscramper#4368 | Also assuming we haven't missed anything, because there are centralized package managers that still have support for lockfiles | 19:11:28 |
| haxscramper#4368 | Without MVS implementation though | 19:11:42 |
| haxscramper#4368 | Also assuming this hard switch won't break whole ecosystem | 19:12:16 |
| haxscramper#4368 | So as arnetheduck just said - if we assume deterministic inputs then MVS would give us deterministic answers. | 19:13:04 |
|  planetis joined the room. | 20:25:28 |
| planetis | In reply to @_discord_449019668296892420:t2bot.io
because they can be changed at will, by humans? if you cant trust the package maintainer 1. dont use the package 2. fork it. seems like a no brainer? | 20:33:24 |
| arnetheduck#9853 | Trust is ephemeral also - you can't predict how humans change - besides, this is a solved problem that doesn't require trust.. Here's a classic example: https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/ | 21:22:54 |
|  bkdrb joined the room. | 22:27:48 |
| 16 Jul 2021 |
 leorize | In reply to @_discord_449019668296892420:t2bot.io
go: https://golang.github.io/dep/docs/Gopkg.lock.html dep is dead already, the new mod system don't use lock files | 00:42:18 |
| leorize | Go's solution to the "git repo might change between pull" is to use a module checksum database: https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md | 00:52:15 |
