This does not look like an issue with Elixir 1.7. The error is most likely caused by the :ecto application not being started before starting repos.
michalmuskala
0
josevalim
Creator of Elixir
Thanks for giving the RC a try. Is this an umbrella app or a path dependency? Because we have found a bug in them: Properly populate top_level field of deps by josevalim · Pull Request #7931 · elixir-lang/elixir · GitHub.
0
tcoopman
baldmountain
I gave 1.7 RC.0 a try with one of our projects. It’s an umbrella app with 3 apps and a phoenix UI app. (Total of 4 in the apps directory.) Tests are all failing with an exception like:
** (ArgumentError) argument error
code: |> D.exceeded_items(
stacktrace:
(stdlib) :ets.lookup(:tzdata_current_release, :release_version)
(tzdata) lib/tzdata/release_reader.ex:47: Tzdata.ReleaseReader.current_release_from_table/0
I tried both erlang 21.0.3 and 20.3. The project works fine under elixir 1.6.6.
I thought it might be an apps startup order issue since my tests were failing with a different ets.lookup call and as long as I do an Application.ensure_started so the ets table has a value that ets.lookup call succeeds. Maybe the issue is that ets.lookup throws an ArgumentError exception if the table doesn’t exist rather than returning :undefined?
Sorry, I’m guessing a little.
0
belaustegui
I have tried my job application and, apart from the expected warnings, everything seems to work properly. The tests are passing and I can not find any errors.
The compilation times also seem to improve. Running time mix compile --force has gone from about 32s to 24s.
Great job and congratulations to the core team, this release looks wonderful 
1
josevalim
Creator of Elixir
Hi @baldmountain, thanks for giving the RC a try. We have found a regression with umbrellas and I believe you have ran into it. We shall release a new RC tomorrow with a fix.
That’s nice to hear! Did you upgrade just the Elixir version or something else? We did optimize the compiler in some places but we were not expecting such a big improvement. 
0
OvermindDL1
My home server was updated to OTP 21 and Elixir 1.7 and I updated the things I’m running on it without much issue, they use ProtocolEx, Meeseeks, and a few other odd things without issue as well. The dependencies are a lot more noisy with warnings upon compilation though, which all seem legit so should be fixed. ProtocolEx had an interesting state where the compiler would not detect a module that definitly exists (seemed like an ordering issue?), but changing a seemingly unrelated line of code fixed it (and putting it back caused it again, and since it didn’t need to belong there and I could move it, then I moved it), and the issue persisted onto 2 different machines with fresh git clone’s and then I tested it with Elixir 1.6 and the issue was there too, so I have no clue what was happening (feel free to check the recent ProtocolEx commit’s, one is marked that it doesn’t work in 1.7, it was that commit that didn’t work on 1.6 or 1.7 on multiple machines here if you are curious as to why the compiler had some kind of ordering issue), but as that ended up not being a 1.7 issue I didn’t report it, and been too busy to start digging in to it to make a PR.
0
belaustegui
I’ve also updated to OTP 21, which seems to provide the other part of the compilation improvements. Updating Elixir only reduced the compilation time to about 29s, and updating OTP 21 reduced them further to only 24s.
Overall I am really happy since we have some nasty module interdependencies that sometimes trigger the recompilation of many files. I am looking into it, but in the meantime with these compilation speed improvements there should reduce the inconveniences on development.
Cheers! 
1
kip
ex_cldr Core Team
@LostKobrakai Mix.Dep.loaded/1 is not in the RC, but it is in master. And as you say, its deprecated. It looks like it might be in the next RC but of course José and team are right to note it was never public API.
I will finish up a workaround today.
I need to push harder to get Cldr version 2.0 done since that removes the need for the compiler (which itself is just a workaround for a poor design choice in 1.x).
Of course the immediate workaround is to not use the Cldr compiler and to manually force recompile ex_cldr and any of its “relatives”.
1