With the upcoming improvements to elm-server and elm-get, it is becoming clear that the names of the various command line tools do not actually match what they do. This is a proposal of how to sort this out.
I propose that the typical workflow will include the following tools:
elm-repl- exactly the same as beforeelm-reactor- combination ofelm-serverand the debuggerelm-package- renamedelm-getthat can manage dependency ranges and transitive dependencieselm-make- a build tool that is aware of bothelm-packageand the compiler
These will all be backed by the compiler which is meant to be used only by other command line tools:
elm-compile- renamed version ofelmin which the--makecleverness has been moved toelm-make
With this structure elm-make can just do the right thing by relying on both elm-package and elm-compiler. It also means that people can make competing build tools or use old-school make files. They can use elm-compiler directly if they really want.
We are moving the time-traveling debugger into elm-server, meaning that you can just start it up and get pause/rewind/replay/continue on any module you want. It will even work with multi-module projects. It will also enable hot-swapping. It is architected such that your editor does not need to know about it, so it will work with whatever setup you prefer. With all these changes, it is very misleading to call it elm-server, especially considering you really should never use it to serve files publicly.
We are also improving elm-get to be a proper package manager. It will be able to resolve dependency constraints, manage transitive dependencies, and install/publish packages. It will also come with a lot of infrastructure for reporting errors to the right people and making relevant information available to users. The info about your package will live in a file called elm_package.json. The trouble comes when you want to start using all this with the compiler.
Say you want to build a project after modifying elm_package.json by hand. The changes to elm_package.json may require a new set of dependencies, perhaps even downloading new packages dependencies. You cannot build until elm-get resolves the dependencies, so elm needs to throw an error saying "run elm-get install" before you can actually build things. That means elm and elm-get need to know about each other. Essentially the problem here is that once you have a real package manager, it makes sense to have a build tool independent of the compiler.
There are a lot of inconsistent and inconvenient names used in elm-get and library.elm-lang.org. The result is that there are useful ideas that are hard to express, like "download the library from the Public Library" or "see if it's in the Public Library." It's weird that a thing called a library is filled with libraries. It's weird that it's ambiguous whether we are talking about physical places called a public libraries or a online thing specific to Elm.
Here's the much rougher brainstorm of how to rename things here:
- Elm Public Library => Elm Package Catalog
- library.elm-lang.org => package.elm-lang.org
elm-get=>elm-package
This has some nice results. Now you can say "check for a graph library in the catalog" and "download the library from the catalog". The idea is that the colloquial name of Elm Package Catalog is The Catalog. If that does not work out, the acronym EPC sounds okayish and epcat sounds pretty great. I'd prefer a real English name if possible though.
It also means that elm-get install becomes elm-package install and elm-get publish becomes elm-package publish. I think all of the variations on this are quite a bit clearer. You can read them Yoda's voice and know what's going to happen even if you don't know anything about elm-package.
As for website names, I think the existing structure is nice, so things would be like this:
package.elm-lang.orgdescribes how to useelm-packageand links to the catalogpackage.elm-lang.org/catalogactually has a listing of all the uploaded packages
Same as before, but with a different subdomain.
With this proposal, it would be possible to move to the git style of routing commands. When people install Elm Platform, they could get a tool called elm that lists all of the things you can do with the platform (i.e. repl, reactor, package, make) making it easy to find all of the features you need.
My experience compiling with ocaml was that it was very hard to figure out how to make things. Should I use a make file? Some compiler flag? One of a couple build tools that are not installed by default? In the end I just decided it was too much trouble and stopped trying. I already have other tools that work.
So the goal of having a router command like elm would be to improve discoverability and encourage consistent naming. That'd mean you could start the REPL by saying elm repl or start the reactor by saying elm reactor.