Elm build tools require network connection the first time they are run in a directory

[eeue56]

[noah@arch elm-repl]$ elm-repl
Elm REPL 0.4 (Elm Platform 0.14.1)
  See usage examples at <https://github.com/elm-lang/elm-repl>
  Type :help for help, :exit to exit
> hello = 5

failed with 'FailedConnectionException "package.elm-lang.org" 80' when sending request to
    <http://package.elm-lang.org/all-packages?elm-package-version=0.4&since=2015-03-07%2016%3A10%3A01.327436%20UTC>

ReferenceError: Elm is not defined
> 

Expected to be able to use the repl offline for any project or any instance. When ELm's installed, so should the current package be installed too, which is used by default unless there's a different elm-package.json

[choedl]

:+1:

[evancz]

What is "the current package"? Or rather, what version of elm-lang/core should be "the default"?

[Apanatshka]

I think the best way to go about this is to have a user-wide ~/.elm/package-cache/ that has a copy of any new package you download, and just have soft-links to that in your project specific elm-stuff.

[mgold]

I'll take the more conservative stance of only doing this for core. It's possible - though highly devious - to retag the release once it's out. We can trust core not to do this, but not arbitrary packages.

[Apanatshka]

@mgold that's another issue, one that I'd like to address separately. (You can simply record the hash of the commit instead of the tag when the new version is published)

[eeue56]

I agree with only doing it with core - the use case of my issue was having installed Elm on a laptop for a new project, before taking a train ride and not realising it needed a network connection to grab elm-package etc.

Most other sandboxing systems (virtualenv, cabal, etc) either copy the system wide version of a package or download it on sandbox creation for initial usage. I'm not sure if this is harmful or not, but for the moment I think core alone should be fine. Anyone using 3rd party libraries is unlikely to be surprised when they need to run something to install libaries.

[AWaselnuk]

I was also surprised by the need for a network connection when I installed Elm today to try it out. Went out on my balcony with no wifi and saw that same error message.

[jamesmacaulay]

I'm here by way of #58, because I think people should be able to open up their terminal after installing elm and type "elm repl" to play around without having to create a project. For that specific use case, what about having an ~/.elm/default-repl directory whose only special "rule" is that it is used as the project directory for any repl started from a directory without elm-package.json?

For most users it would just mean that they have one less annoyance when they want to play around, and for some other users they could customize their default repl environment in a natural way. When there is no elm-package.json present, elm-repl could print out a line before anything else that says something like "no elm-package.json found, using ~/.elm/default-repl/package.json" which would aid in discoverability.

[jamesmacaulay]

Hmm, now I'm confused. elm-repl seems to be working fine for me in directories without elm-package.json, now that I've gone and created a project directory somewhere else with elm package install, I guess because it put stuff in ~/.elm. But before, right after I first installed 0.16, it gave me this error when working with a previous elm-package.json that was in my home directory left over from a 0.15.1 repl:

☺  elm repl
---- elm repl 0.16.0 -----------------------------------------------------------
 :help for help, :exit to exit, more at <https://github.com/elm-lang/elm-repl>
--------------------------------------------------------------------------------
> add a b = a + b
Error reading file elm-package.json:
    Problem with the `repository` field.

Upper case characters are not allowed in package names.

>

Then when I deleted that elm-package.json, it gave me this error instead:

☺  elm repl
---- elm repl 0.16.0 -----------------------------------------------------------
 :help for help, :exit to exit, more at <https://github.com/elm-lang/elm-repl>
--------------------------------------------------------------------------------
> add a b = a + b
elm-make: elm-package.json: openBinaryFile: does not exist (No such file or directory)

>

But yeah, now everything works fine. What changed to make it stop caring that it couldn't find an elm-package.json?

[sjfloat]

Not sure I understand; is there a fix proposed for this? This one seriously reduces the likelihood of adoption where I work.

[eeue56]

@sjfloat There is a change to elm-package that I've been working on that will hopefully be in 0.17 that will address this issue

[sjfloat]

Good to hear, thanks!

[jottr]

Any update on this? I'm on 0.17.0 and wanted to use the idle time of a long flight to learn elm. I got stopped in my tracks right after firing up the repl. Is there a workaround for the time being?

[mgold]

If the core libraries aren't on your machine, no. If they are, try copying elm-stuff and elm-package.json to the new directory.

[pdamoc]

This is still a problem in 0.18.

The top story currently on /r/elm is a twitter post about it.

What would be the disadvantages/issues of the solution proposed by @Apanatshka? Is it difficult to implement?

[eeue56]

Peter, I have added this issue to a design document for commonly known problems and elm-package improvements for 0.19. Maybe it will be fixed then :)

[gilesbowkett]

@eeue56 if the installer gets a new release every time Elm does, what about just manually including the core language zipball with each installer release? too hacky?

[anyonecancode]

How does yarn handle this? I can do yarn --offline <my command> and, assuming I've previously done either yarn install, can develop offline fine, and was surprised to find that this was not the case with elm-make or elm-reactor.

Edit -- in my particular case I just realized I was in the wrong directory when running elm-make, so the "not working offline" might not actually have been true, but I do want to leave my suggestion of looking to JavaScript's yarn tool as a possible source of inspiration.