Item — HN Reader

This is a great observation.

By default, using a name like `janedoe91/fibonacci` pulls the latest version of that particular scrap from the scrapyard. But all of its references are baked-in unless the author updates them.

The way around this is that consumers are empowered to use whatever forcing upgrade strategies they want. All scraps are transparent, so you can pipe everything through an "upgrader" scrap before execution, which replaces dependencies all the way down the stack with their latest versions. I'm sure many of these upgraders will exist depending on what types of tradeoffs you're looking for.

1 comments

Can scraps be versioned? Is it possible to see the available versions of a scrap? Could you add support for dependency management?

MVS is a nice and easy algo: https://research.swtch.com/vgo-mvs

Yes, scraps can be versioned:

  user/my-scrap@99

And you can check the available versions of the scrap by querying the scrapyard directly. But omitting the version will just use the latest:

  user/my-scrap

Each scrap contains a full list of its own dependencies, so there is no need for external dependency management.

All scraps are transparent, so you can create your own tools to manually tweak/replace dependencies before execution:

  $ cat my-scrap.ss \
    | scrap apply my-dependency-helper \
    | scrap eval

This fixer would have to walk the dependency tree. What if something breaks contract in the middle, something I do not control? That sounds like a huge burden on developers with lots of risk.

Why opt out of proper dependency management?

You can emulate traditional dependency management by pinning the versions of all your scraps, and updating them selectively:

  user/my-scrap@414

> This fixer would have to walk the dependency tree.

Remember that the language itself works like a merkle tree and every scrap can be cached anywhere. To keep the language and tooling extremely simple, I think this works well enough.

> What if something breaks contract in the middle, something I do not control?

Everything is strongly typed, so there are certain guarantees about how things can break and update. You can easily make tooling that never makes breaking changes.

People can always introduce implementation bugs into their code though, but that's inevitable even with dependency management.

> That sounds like a huge burden on developers with lots of risk.

I will try my hardest to reduce that burden. I think I can put some sane defaults in the tooling surrounding the language to obviate the need for traditional dependency management.

So the issue is see with lack of dep management...

1. My code depends on dep A and B, which also depends on A.

2. A has some issue, so I update my reference, but B does not.

3. Given dependencies are bundled, B still contains the bad A.

So how can I updated the A used by B? (Without effectively forking B) This is more a problem with bundled or censored dependencies than the lack of dependency management. Dep Mgmt aims to solve this issue by having only one copy of a dependency

Except in many dep management systems they purposefully don’t keep only one copy to allow multi versions to run side by side and other benefits like having a deliberate piece by piece upgrade of everything in the dependency tree. Forcing all deps to be on the same version of all other deps sounds like it would cause more problems than it would solve.

Also the ideas of immutable deps mean this property of “duplicated” deps comes naturally.

I think many bugs can come from what you propose. A large dev tree would need everyone in the tree to coordinate to upgrade all at once. That seems basically impossible for any dep tree. Especially in a system where the deps are small code snippets like this one. Even small programs can have 1000s of deps.

Why are you implying that this model is “normal” dep management?

Aka “the diamond dependency problem”.

If the “old” A has a severe vulnerability and the “new” A has breaking changes - then there is no solution other than to avoid/replace/fork B until B is upgraded.