Distillery: version 'nil' in sys.config in Phoenix umbrella app

Questions / Help
, , , ,
1

I have an umbrella app generated with Phoenix 1.3.0-rc.2, in which I currently have one app intended to be run on its own server with its own database; this child app is very simple and will act as an HTTP API and data store, and the other apps, one of which I plan to have read data from the first child app, will come later.

As per Distillery’s Phoenix walkthrough, I have this in the child app’s config/prod.exs:

config :my_child_app, MyChildApp.Web.Endpoint,
  # ...
  version: Mix.Project.config[:version]

In the umbrella app’s rel/config.exs:

release :my_child_app do
  set version: current_version(:my_child_app)
end

However, in the resultant release’s sys.config I get {version,nil},.

If I add a version key (which wasn’t there in the files generated with phx.new) to the umbrella parent app’s project function’s list, sys.config gets the version value from it.

def project do
  [apps_path: "apps",
   start_permanent: Mix.env == :prod,
   deps: deps(),
   version: "0.0.1"]
end

When I run iex -S mix from the umbrella’s root and then the child app’s directory, I get the same results as seen above when doing Mix.Project.config[:version].

Is this expected/okay, or should Distillery be using the version from the child app when it generates sys.config? Should I make sure that sys.config always has a non-nil version value?

Distillery’s Phoenix walkthrough says:

version ensures that the asset cache will be busted on versioned application upgrades (more on this later)

2

The release is running okay on my server now that I’ve got that configured, so it seems like version being nil in sys.config isn’t a problem in itself. Does anyone know if it may become one for any reason, perhaps when doing hot upgrades (which I’m not planning to do anytime soon)?

3

As I recall, if you have multiple deployed versions and you start one then it starts the ‘last-most’ version by default, running migrations (not called that in erlang, they are just function tuples that are called on version change) as necessary (such as if needing to update data in mnesia from an older format to another). If you deploy a version number over a version number then it just starts it up without migrations as I recall.

4

Thanks. And is the version in sys.config what determines erlang’s identification of the app version? (I ask as 0.0.1 is in other files in the release, such as my_child_app.rel and my_child_app.script.) Worth an issue for Distillery at Github?

5

I’m like 80% certain that is a Yes.

Possible, the author is around here too as @bitwalker I think?

1 Like
6

Thanks. And is the version in sys.config what determines erlang’s identification of the app version? (I ask as 0.0.1 is in other files in the release, such as my_child_app.rel and my_child_app.script.)

The version setting recommended in the Phoenix walkthrough is simply to ensure that assets get hot upgraded (because internally Phoenix updates it’s reference to the asset path if the config changes, so this value is guaranteed to trigger that change). It’s not used for any other purpose.

Worth an issue for Distillery at Github?

This isn’t an issue with Distillery - the problem here is that using Mix.Project.config[:version] is not the desired way to get the version of a given application (because as seen above it’s use in an umbrella app does not produce a valid version), instead use Application.spec(:myapp)[:vsn].

3 Likes
7

I see. Many thanks for the thorough explanation!

Would it be worth updating the Phoenix-related pages to use Application.spec to cover off usage of umbrella projects, or perhaps adding a note? If so, should I have a crack at a small PR?

1 Like
8

Sure! That’d be great :slight_smile:

1 Like
9

Is configuring Endpoint.version still recommended in latest Distillery+Phoenix? Is it only for hot upgrades?