Package collaboration workflow

It certainly was a useful suggestion.

Just to be clear, I am not advocating for a tool that lets you write and share new packages containing kernel code. I would like a tool that supports 2 use cases, and I think these do not in any way subvert the purity of Elm packages:

  1. Private packages (not containing kernel code).

  2. The ability to modify packages that do contain kernel code and build them locally. This is to assist with bug fixes or other feature experimentation. It would not be possible to publish these as they would need to be in the elm or elm-explorations namespaces. Technically it would be possible to share them as any override to the git URL would be supported by this tool - but I think end users would be very aware that they are using forked kernel packages. I think not being able to publish them to the official repo would make them irrelevant anyway.

I’d sooner have use case 1 over use case 2. Perhaps use case 2 has a better solution?

For example, TSFoster and myself collaborated on a fix for a non tail recursive function in the debugger that is occasionally blowing the stack on larger models. I never figured out how to test the patch though, so have never created a PR for it. Seems a shame to miss out on little bug fixes like this for lack of a simple way to test them:

4 Likes