sebastianszturo / countries Goto Github PK

Swiss VAT rates have changed as of 1 Jan 2018. The upstream countries gem has already incorporated these changes. Could you please release an update with the latest data? Thanks! 💛

The subdivision id field is a charlist not a string. Is this by design?

Hey I ran into a problem where the Subdivisions data was not being loaded.

I also saw that the data has been moved into the priv directory which solve the problem where the data is missing from release. However the latest version 1.5.1 is not a reflection of what is in the master branch.

Any chance we can get an updated version in hex?

As far as i can see, any call to this library will result in parsing YAML files.

How about creating that lookup table and data on compile time, instead on runtime? That would speed up any call to this library an eliminate any disk access.

Maybe have a look at some code i used to generate functions bodies while compiling here:
https://github.com/h4cc/slugger/blob/master/lib/slugger.ex#L69

Hi!

I've encountered an issue with this package while using it in an app running on Heroku.
While countries are loaded fine, and can be retrieved without issue, the same doesn't hold true for subdivisions.

Cause

I've managed to track this issue all the way to the __DIR__ in subdivisions.ex which got (somehow) expanded during compile time to /tmp/....

This is visible if you open the Elixir.Counties.Subdivisions.beam file on the instance. Since the Heroku Elixir buildpack runs the app from /app, but Heroku builds/compiles the app in /tmp this leaves an incorrect path in the compiled .beam file and when run the application can't locate the correct yaml file and fall-back to [].

Countries work because they are loaded at compile-time, in contrast to subdivisions which are loaded dynamically. And rightly so, as loading all subdivisions into memory would be quite a large overhead.

Workaround

I've found two temporary workarounds for this issue.

1. Connect to an running instance using heroku ps:exec and run mix deps.compile countries --force
2. Find the build path, or use $BUILD_PATH if set, run heroku ps:exec and then ln -s $BUILD_PATH /app/deps

Both workarounds are temporary as you can't be sure when will Heroku spin up a new Dyno for your application, and the workaround doesn't survive redeploys.

Solution

I'm not aware of any way to solve this. This is an attempt to make the issue visible to others.
My instinct tells me that, perhaps, it would be better to store data in the priv direcotry and use erlang's :code.priv_dir(Countires) or Elixir's Application.app_dir(:countires, "priv/countires") to access the data.

Reproduction

1. Spin up a Heroku instance with any Phoenix application on Elixir 1.6.5 and erlang 20.1 using countries.
2. Run iex -S mix
3. Enter Countries.filter_by(:alpha2, "US") |> List.first() |> Countries.Subdivisions.all()

It returns an empty List

Expected

1. Spin up a Heroku instance with any Phoenix application using countries.
2. Run iex -S mix
3. Enter Countries.filter_by(:alpha2, "US") |> List.first() |> Countries.Subdivisions.all()

It returns an non empty List

Configuration

Elixir 1.6.5
Erlang 20.1

Wonder if there is any reason why Subdivisions all have name translations while mother countries does not have them

The info is existing in countries gem under https://github.com/hexorx/countries/tree/master/lib/countries/cache/locales

there is a small delay when loading the yaml files that should be moved into its on application and run during start

Hey @SebastianSzturo @steffenix thanks so much for your work on this library.

Is it still maintained? Do you have plans to merge open PRs and take care of outstanding issues? Can we, as a community, help you out?

Thanks again for you work for the Elixir community. I look forward to be able to contribute.

- Daniel ❤️

I am using the countries list to get a country name using it's ISO3166 code.

This is done easily using the :number attribute of a country.

Example: Countries.filter_by(:number, "250")

This works great in most cases, given that the code is a string. However, sometimes the :number attribute is stored as an integer, for example country with ISO code 48 (Bahrain) or Bolivia. For those countries I need tu use this: Countries.filter_by(:number, 48)

Obviously, this isn't a major issue as I'm just bypassing this by using a map function on all countries to convert to either string or an integer. Just converting all codes solves this problem.

But I thought I'd share this issue as it would make the list cleaner and debugging less confusing when using country ISO3166 codes to just use the same type for all countries, whether string or int.

Thanks!

Received the following deprecation warning on a new project build with countries 1.5.0:

==> countries
Compiling 6 files (.ex)
warning: "not expr1 in expr2" is deprecated. Instead use "expr1 not in expr2" if you require Elixir v1.5+, or "not(expr1 in expr2)" if you have to support earlier Elixir versions
  lib/loader.ex:55

Build environment is Ubuntu 18.04 LTS, Elixir/OTP:

$ elixir --version
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]

Elixir 1.7.0 (compiled with Erlang/OTP 20)

Stacktrace:

== Compilation error on file lib/country.ex ==
** (ArgumentError) Access is not a protocol, cannot derive Access for Countries.Country
    (elixir) lib/protocol.ex:76: Protocol.assert_protocol!/2
    (elixir) lib/protocol.ex:591: Protocol.derive/5
    (stdlib) lists.erl:1337: :lists.foreach/2
    (elixir) lib/protocol.ex:579: Protocol.__derive__/3
    lib/country.ex:3: (module)

On Elixir 1.1.1

correct is: Taiwan, Republic of China

Something like:

languages_official:
  en: english
languages_spoken:
  en: english

%Country {
  languages_official: %{"en" => "english"}
  languages_spoken: %{"en" => "english"}
}

Hey, thanks for the great work! :)

Would you mind updating the package on Hex.pm? Some issues that was already fixed like #5 is still there.

Thanks!