Etlas 1.0.2.0 fails to read index

[tom91136]

So, following the installation guide for a fresh binary install on Windows 10, the output of the first invocation of etlas init looks like this:

......
Config file path source is default config file.
Config file C:\Users\Tom\AppData\Roaming\etlas\config not found.
Writing default configuration to C:\Users\Tom\AppData\Roaming\etlas\config
Discovering the installation paths for your Eta executables...
No existing installation found for 'eta'.
Attempting to download binaries...
Downloading the latest package lists from:
- hackage.haskell.org
- etlas.typelead.com
Updating binary package index.
C:\Users\Tom\AppData\Roaming\etlas\binaries\6899fa2dcac85d20d417-8f2e61d843ea88e4f30ab3f81ca0e396.ssl.cf5.rackcdn.com\index: openFile: does not exist (No such file or directory)

Subsequent calls such as init and update results in:

> etlas init
Discovering the installation paths for your Eta executables...
No existing installation found for 'eta'.
Attempting to download binaries...
etlas: Unable to find an Eta binary for your platform.
Either install from source or try the following:
Run `etlas update` and try again.
If that doesn't work, please report this as a bug at

https://github.com/typelead/eta/issues/new

specifying your Etlas version.

> etlas update
Downloading the latest package lists from:
- hackage.haskell.org
- etlas.typelead.com
etlas: Could not read index. Did you call 'checkForUpdates'?

And the etlas version is:

> etlas --version
etlas version 1.0.2.0
compiled using version 2.1.0.0 of the etlas-cabal library

If matters, this happened on Windows 10 1703 Build 15063.540

[tom91136]

Ok, I've check the source of Etlas, it seems that HttpUtils.hs's implementation of curlTransport behaved strangely with Gow. I've confirmed this by removing Gow from my PATH; adding --http-transport=powershell also fixed the issue as expected.

The actual call to curl looked like this:

"C:\Program Files (x86)\Gow\bin\curl.exe" "http://hackage.haskell.org/snapshot.json" "--output" "C:\Users\Tom\AppData\Local\Temp\transportAdapterGet633426500" "--location" "--write-out" "%{http_code}" "--user-agent" "etlas/1.0.2.0 (windows; x86_64)" "--silent" "--show-error" "--dump-header" "C:\Users\Tom\AppData\Local\Temp\curl-headers1916915724.txt" "--header" "Cache-Control: no-transform"

A second call to curl is made ~1 second later:

"C:\Program Files (x86)\Gow\bin\curl.exe" "http://hackage.haskell.org/01-index.tar.gz" "--output" "C:\Users\Tom\AppData\Local\Temp\transportAdapterGet48275436" "--location" "--write-out" "%{http_code}" "--user-agent" "etlas/1.0.2.0 (windows; x86_64)" "--silent" "--show-error" "--dump-header" "C:\Users\Tom\AppData\Local\Temp\curl-headers3239114604.txt" "--header" "Cache-Control: no-transform"

It seems that Etlas did not wait for the process to return. From what I can see, Etlas initiated the curl call and then immediately reported error while leaving the curl process to download the file(of which, is left at-is in the Temp directory)

Not sure if this is a bug or an issue with Gow.

[rahulmutt]

What's the exact failure?

Can you show the output of etlas init -v3 so we can see a full trace?

[rahulmutt]

Thanks for the analysis btw!

[tom91136]

Hmm, there isn't a failure to speak of, etlas seems to forget about the curl process entirely and think that the index file is not there.

Here's the output with -v3 and Gow in PATH

> etlas init -v3
......
Config file path source is default config file.
Config file C:\Users\Tom\AppData\Roaming\etlas\config not found.
Writing default configuration to C:\Users\Tom\AppData\Roaming\etlas\config
no user package environment file found at C:\Users\Tom\Desktop\foo
Discovering the installation paths for your Eta executables...
No existing installation found for 'eta'.
Attempting to download binaries...
Downloading the latest package lists from:
- hackage.haskell.org
- etlas.typelead.com
Updating binary package index.
C:\Users\Tom\AppData\Roaming\etlas\binaries\6899fa2dcac85d20d417-8f2e61d843ea88e4f30ab3f81ca0e396.ssl.cf5.rackcdn.com\index: openFile: does not exist (No such file or directory)

[tom91136]

I'll compare Gow's curl with a generic linux distro's curl to see if the behavior is different. I think this is becoming more of a system configuration issue and has nothing to do with etlas.

Is there any particular reason why platform dependent tools are prefered instead of plainHttpTransport? plainHttpTransport seem fine as it uses Network.HTTP which should be immune to these kind of issues.

[rahulmutt]

Cool sounds good.

They're more robust and handle all the edge cases in HTTP. curl is used by a lot of people and I'm not sure Network.HTTP gets as much attention.

[rahulmutt]

While this is not etlas's problem exactly, I'd be happy to accept a patch that handles this case with minimal changes.

[hardliner66]

As long as the installation and the issue with hackage aren't resolved, there should at least be better documentation on how to install. Otherwise people who seriously want to try eta may get turned off.

It should also be documented that the installation with GOW will fail.

[rahulmutt]

I'd rather come up with a fix that handles GOW rather than having it silently fail. Windows binary installation seems fine under other conditions.

So the way I can reproduce this is by installing GOW and placing it in the path, correct?

[hardliner66]

Yes. But for me it also failed with plain CMD and GOW not installed.

[rahulmutt]

Can you share etlas update -v3 so that I can try to reproduce the state of your system?