thehunmonkgroup commented 5 years ago

Steps to reproduce

Trying to build production version of my app using latest release of distillery, getting 'No such module: asn1ct' error.

Debian Stretch, erlang-asn1 package is installed, and that module seems available:

poof@poof:/var/local/git/poof/staging$ iex
Erlang/OTP 21 [erts-10.2] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1]

Interactive Elixir (1.7.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> import :asn1ct
:asn1ct

I'm a bit lost how to debug further from here!

Verbose Logs

Description of issue

What are the expected results? Build should succeed
What version of Distillery? 2.0.12
What OS, Erlang/Elixir versions are you seeing this issue on? Erlang/OTP 21 [erts-10.2] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1] Elixir 1.7.4 (compiled with Erlang/OTP 20)

If possible, also provide your rel/config.exs, as it is often my first troubleshooting question, and you'll save us both time :)


# Import all plugins from `rel/plugins`
# They can then be used by adding `plugin MyPlugin` to
# either an environment, or release definition, where
# `MyPlugin` is the name of the plugin module.
Path.join(["rel", "plugins", "*.exs"])
|> Path.wildcard()
|> Enum.map(&Code.eval_file(&1))

use Mix.Releases.Config,

This sets the default release built by `mix release`

default_release: :default,
# This sets the default environment used by `mix release`
default_environment: Mix.env()

For a full list of config options for both releases

and environments, visit https://hexdocs.pm/distillery/configuration.html

You may define one or more environments in this file,

an environment's settings will override those of a release

when building in that environment, this combination of release

and environment configuration is called a profile

environment :dev do

If you are running Phoenix, you should make sure that

server: true is set and the code reloader is disabled,

even in dev mode.

It is recommended that you build with MIX_ENV=prod and pass

the --env flag to Distillery explicitly if you want to use

dev mode.

set dev_mode: true set include_erts: false set cookie: :"zmX|QZgJjoSTA%I!t}VE$PQB,Q$d@o0W3}[yNmP;lcla8MB{0825v(N:x|rgXm" end

environment :prod do set include_erts: true set include_src: false set cookie: :"u8bO%bdAa*@e1>11KH:OPEuC[~<=TVD7B;xY{AY3IzVM,%i_jt0</SLq1Dy`gg" set vm_args: "rel/vm.args" end

You may define one or more releases in this file.

If you have not set a default release, or selected one

when running `mix release`, the first release in the file

will be used by default

release :poof do set version: current_version(:poof) set applications: [ :runtime_tools ] end

OvermindDL1 commented 5 years ago

That usually means that application wasn't added to the extra applications list in the mix.exs file. What is the contents of your mix.exs file?

thehunmonkgroup commented 5 years ago

Yep, adding :asn1 application to extra_applications: did fix the issue...

Still a bit mystified though. I don't use ASN.1 stuff anywhere in my app, if it's used by a dependency, wouldn't it be the dependency's job to fire it up?

Also, how do I find out what is requiring the asn1ct module in the first place?

OvermindDL1 commented 5 years ago

wouldn't it be the dependency's job to fire it up?

I would think so...

Also, how do I find out what is requiring the asn1ct module in the first place?

Hmm, well mix deps.tree will print the dependency tree, but if some library isn't adding it to their dependencies... Your best bet might be running mix xref callers :asn1ct, I'm not sure if that will scan dependencies, I think it only does the current project, but running that command over everything in the deps directory should work, like via for d in deps/*; do cd $d; mix deps.get && mix compile; cd ../..; done; for d in deps/*; do cd $d; mix xref callers :asn1ct; cd ../..; done or so? (should print results at bottom of listing as it does all the acquisition and compiling in a loop first)

thehunmonkgroup commented 5 years ago

mix xref callers :asn1ct didn't return anything for my project.

Also ran the bash commands for all my project deps, nothing there either...

I suppose this means it's probably called by a dependency of one of my dependencies? Is there any other solution to find it besides writing a more complex script that iterates the entire deps tree recursively?

OvermindDL1 commented 5 years ago

You could just grep -R asn1ct . from the root of the project to find every single possible link to it? :-)

thehunmonkgroup commented 5 years ago

[root@poof.stirlab.local:/var/local/git/poof] # grep -R asn1ct .
grep: ./_build/test/lib/ssl_verify_fun/ebin: No such file or directory
[root@poof.stirlab.local:/var/local/git/poof]

What the hell??

OvermindDL1 commented 5 years ago

Is hackney in your dependencies? What is your full mix.exs file?

thehunmonkgroup commented 5 years ago

Full mix.exs:

defmodule Poof.Mixfile do
  use Mix.Project

  def project do
    [
      app: :poof,
      version: "1.2.3+006",
      elixir: "~> 1.7",
      elixirc_paths: elixirc_paths(Mix.env),
      compilers: [:phoenix, :gettext] ++ Mix.compilers,
      start_permanent: Mix.env == :prod,
      aliases: aliases(),
      deps: deps()
    ]
  end

  # Configuration for the OTP application.
  #
  # Type `mix help compile.app` for more information.
  def application do
    [
      mod: {Poof.Application, []},
      extra_applications: [:asn1, :logger, :runtime_tools],
    ]
  end

  # Specifies which paths to compile per environment.
  defp elixirc_paths(:test), do: ["lib", "test/support"]
  defp elixirc_paths(_),     do: ["lib"]

  # Specifies your project dependencies.
  #
  # Type `mix help deps` for examples and options.
  defp deps do
    [
      {:phoenix, "~> 1.3.4"},
      {:phoenix_pubsub, "~> 1.0"},
      {:phoenix_ecto, "~> 3.2"},
      {:postgrex, ">= 0.0.0"},
      {:phoenix_html, "~> 2.10"},
      {:phoenix_live_reload, "~> 1.0", only: :dev},
      {:gettext, "~> 0.11"},
      {:plug_cowboy, "~> 1.0"},
      {:timex, "~> 3.4.0"},
      {:timex_ecto, "~> 3.2"},
      {:uuid, "~> 1.1"},
      {:basic_auth, "~> 2.2"},
      {:dynamic_server_manager, "~> 0.0.10"},
      {:distillery, "~> 2.0"},
      {:swoosh, "~> 0.13"},
      {:tesla, "~> 1.2.0"},
      {:jason, "~> 1.1.0"},
      {:mox, "~> 0.3", only: :test},
    ]
  end

  # Aliases are shortcuts or tasks specific to the current project.
  # For example, to create, migrate and run the seeds file at once:
  #
  #     $ mix ecto.setup
  #
  # See the documentation for `Mix` for more info on aliases.
  defp aliases do
    [
      "ecto.setup": ["ecto.create", "ecto.migrate"],
      "ecto.clean": ["ecto.drop", "ecto.setup"],
      "ecto.seed": ["run priv/repo/seeds.exs"],
      "ecto.reset": ["ecto.clean", "ecto.seed"],
      test: ["ecto.create --quiet", "ecto.migrate", "test"]
    ]
  end
end

I don't have a direct dep for hackney, but I'm pretty sure one of my deps does...

OvermindDL1 commented 5 years ago

Hmm, it looks like it might actually be timex? It's calling the :asn1_* conversion routines. Might also be cowboy1 as it performs asn1 code generation but it looks like that happens entirely compile-time, unsure if there is any run-time component of it. (You should upgrade to cowboy2, it's faster, you do that by bumping plug_cowboy's version to 2.0 ^.^)

So looks like you might need to keep it added to your extra's list then. But the dependencies you have that touch it are cowboy and timex. :-)

It also doesn't look like timex sets it as a required application, so that might be worth a PR to them.

thehunmonkgroup commented 5 years ago

Doesn't look like I can update plug_cowboy until I update phoenix:

Failed to use "cowboy" because
  phoenix (version 1.3.4) requires ~> 1.0
  plug_cowboy (versions 2.0.0 and 2.0.1) requires ~> 2.5
  swoosh (versions 0.16.0 to 0.21.0) requires ~> 1.0.1 or ~> 1.1 or ~> 2.4

I'll file an issue with timex to see if adding :asn1 application to extra_applications: is feasible.

OvermindDL1 commented 5 years ago

Doesn't look like I can update plug_cowboy until I update phoenix:

Ah yeah that is true, you need Phoenix at least 1.4 for it. I'd recommend updating though! :-)

And yeah, adding the application is fine. :-)

thehunmonkgroup commented 5 years ago

Well, I spent several hours upgrading to Phoenix 1.4, and now I get a completely different build error... :(

==> Release failed with multiple errors:
    Multiply defined module: 'Elixir.Collectable.Ecto.Adapters.SQL.Stream'

Detailed logs below. Tried looking for that error via Google, nada...

Verbose Logs

OvermindDL1 commented 5 years ago

Multiply defined module: 'Elixir.Collectable.Ecto.Adapters.SQL.Stream'

Anytime you see Multiply defined module that means the module is defined multiple times through more than 1 dependency. Can you post your complete mix.exs file again? :-)

Also, the ElixirForums are a better place for these questions, but if bitwalker doesn't mind... ^.^

thehunmonkgroup commented 5 years ago

Yeah you're right, this issue is hitting 'scope creeep' ;)

Re-posted in Elixir Forum here: https://elixirforum.com/t/distillery-build-error-multiply-defined-module-elixir-collectable-ecto-adapters-sql-stream/19489

Any further help greatly appreciated :)

thehunmonkgroup commented 5 years ago

Final update: After resolving the error I reported in https://github.com/bitwalker/distillery/issues/627#issuecomment-455009534 I was able to also remove :asn1 from extra_applications:, which was my workaround to the problem in this original issue report.

So it seems that issue was resolved by either:

My upgrade to Phoenix 1.4.x, and thus Cowboy 2.6.x
Wiping the _build directory before trying to rebuild (which is what fixed the Multiply defined module error)

bitwalker / distillery

Release build fails with 'No such module: asn1ct' error #627

Steps to reproduce

Verbose Logs

Description of issue

This sets the default release built by `mix release`

For a full list of config options for both releases

and environments, visit https://hexdocs.pm/distillery/configuration.html

You may define one or more environments in this file,

an environment's settings will override those of a release

when building in that environment, this combination of release

and environment configuration is called a profile

If you are running Phoenix, you should make sure that

server: true is set and the code reloader is disabled,

even in dev mode.

It is recommended that you build with MIX_ENV=prod and pass

the --env flag to Distillery explicitly if you want to use

dev mode.

You may define one or more releases in this file.

If you have not set a default release, or selected one

when running `mix release`, the first release in the file

will be used by default

Verbose Logs

bitwalker / distillery

Release build fails with 'No such module: asn1ct' error #627

Steps to reproduce

Verbose Logs

Description of issue

This sets the default release built by mix release

For a full list of config options for both releases

and environments, visit https://hexdocs.pm/distillery/configuration.html

You may define one or more environments in this file,

an environment's settings will override those of a release

when building in that environment, this combination of release

and environment configuration is called a profile

If you are running Phoenix, you should make sure that

server: true is set and the code reloader is disabled,

even in dev mode.

It is recommended that you build with MIX_ENV=prod and pass

the --env flag to Distillery explicitly if you want to use

dev mode.

You may define one or more releases in this file.

If you have not set a default release, or selected one

when running mix release, the first release in the file

will be used by default

Verbose Logs

This sets the default release built by `mix release`

when running `mix release`, the first release in the file