Private Package Tool Spec

[rupert]

@dillonkearns

It would be nice to be have a way to avoid cluttering up the main Elm package repository with packages that depend on specific runtime requirements.

Yes, that is precisely my thinking too - that is why I put:

“If a hacked version of the compiler is needed, it must have the publish command removed, so as to ensure the package.elm-lang.org site is treated as read-only, and source of truth.”

It is also the intended use case for tags.

• An alternate compiler with different runtime requirements should use its own set of tags to describe them. The idea being that it is very clear that these are not part of the Elm kernel.
• It should also be very clear that having a different runtime carries a risk, if depending on Elms undocumented kernel interface.
• It should also be very clear that there is absolutely no obligation on Elm to avoid breaking changes to that interface, or to port third party packages using it, to new versions of Elm.

Another possibility is that an Elm implementation could arise that compiles to a completely different back-end. A known example is Morphir, which compiles Elm to Scala. As it is focussed on business rules, I am guessing its runtime requirement is just core, and it does not need vdom or browser at all:

Morphir-elm: portable business logic in Elm

Elm really is a delightful language for reliable webapps and it can do so much more! I would like to introduce Morphir: an open-source project where Elm is used to build business logic that runs anywhere. Morphir’s backbone is an intermediary representation that allows us to capture the application’s business logic in a technology agnostic manner. Using the IR as the integration point gives us a lot of flexibility in how we build, verify and run the business logic. Over the years we experimente…

With the tags it would be easy to set up a mirror of the Elm package site, just for core, and get all packages that can compile on core alone - mostly data structures/algorithms/update helpers/etc. Anyone using Morphir would then have a clear view on what is available to them.

Of course, as Morphir compiles to Scala, it needs to completely re-implement the core kernel packages with Scala implementations, and needs to have identical APIs to them. The API comparison can be automated. Its private package server would have the core packages in it, maybe provided as .jar files (a JVM thing). It would implement the core tag, but not using the originals. Or maybe it might use the originals, and run them as javascript on the JVM (which is also a thing). Scala also compiles to JS doesn’t it?

Also worth noting that Morphir is not an identical implementation of Elm as the original - it has 64-bit integers for one thing. Some kind of formal language spec and test suite might eventually be needed for Elm. The beauty of Elm is that it is such a small language, so this is a less daunting proposition than for many languages.

elm-pages is an interesting example too. I originally assumed it would not depend on browser, but I see it does - well of course it does, because it runs client side too. I think it would be possible to split the client side out into a separate package, if you ever wanted too. But elm-pages was what got me thinking that vdom and browser should be separate tags - since you need vdom for server side rendering, but not browser. I can imagine a future where elm-pages has a different implementation when doing server side rendering, but runs with pure Elm on the client side.

Also note, in the spec I put:

2. Confirm the package does not contain ports.
3. Confirm the package does not contain kernel code.

No intention at the present time of overriding these restrictions. I just want to focus on doing private packages with minimal disruption to the current system. The reason for introducing the tags idea now, is that its going to be easier to get that in right from the start, even though it is not immediately useful.