3 ms·
I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of pack
by philsnow 6y ago
I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have).
Maybe it could be solved by type checking during dependency resolution time: instead of just checking version numbers, also check capabilities that transitive dependencies declare.
Maybe you could slowly boil the ocean by assuming that everything that doesn't declare required capabilities implicitly requires the "ALL" capability, and triage+prioritize a growing core of packages that have explicit capability requirements. In my mind it's kind of like purifying functions in a library: you start at the lowest level / leaves of the call graph and make sure they don't do any I/O, and then the things that call them can be made pure and so on up the chain.
- ori_b 6y ago> I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have). That sounds like it would be working. If you declare that your package doesn't need network, and it fails because it used the network, that sounds like a bug was caught.