Search path for *.tar.gz releases

[supersasha]

When we building a new release as tar archive we get something like myrel-0.0.2.tar.gz, i.e. in the <release-name>-<release-version>.tar.gz form.

Then we install it:

 $ ./bin/myrel install 0.0.2

and get an error:

 Unpack failed: {no_such_file,"<path-to-releases-dir>/releases/0.0.2/myrel.tar.gz"}

So the install script looks for the tar archive at <path-to-releases-dir>/releases/<release-version>/<release-name>.tar.gz.

On the one hand, it is not a big problem to parse file name, extract release's name and version, then create new dir and copy the renamed file in there. On the other side, is there any reasonable cause for that? Why not simply look for <release-name>-<release-version>.tar.gz file in the releases or even some configurable directory?

May be I've missed something, but it seems that the search path is hard-coded in templates/install_upgrade_escript.

[tsloughter]

Hey, sorry I missed this ticket opening. I'll look this weekend.

[tsloughter]

Sorry I didn't get back on this earlier. This is actually a common question and I'm not really sure how to address it.

Since the tarball would be "deployed" in some fashion to the target machine to be used it doesn't make sense that it would need to be created in a form equivalent to how it would be required to be on the target. So the <name>-<vsn>.tar.gz made the most sense to me.

For example at Heroku we then upload that to s3 and instances will fetch a certain vsn from there to disk under the appropriate directory and name before running install.

But the confusion has come up enough times that it may be best to change it to output to releases/<vsn>/<name>.tar.gz.

I'll look at doing that in the near future.

[lrascao]

@tsloughter #505 proposal could possibly be a solution to this issue

[lrascao]

closing since #505 has since been merged