jeremyjh

jeremyjh OP

In case anyone is following or finds this topic I wanted to post an update to mention 0.4.0 release is finally done and released on hex.pm. I thought it would take a couple of weeks but I kept adding features and then life happened and here it has been four months! I think the new task is much improved with an infusion of the dialyze PLT management code but I made a lot of other changes as well. I even wrote tests!

I do have further work planned; I want to get away from shelling dialyzer while still supporting the raw argument forwarding. I would also like to have a guard/watch type mode. If you have any other ideas for features feel free to open Github issues.

0
Post #31
christopheradams

christopheradams

Great work @jeremyjh the new release works great for me so far and the local archive is a welcome addition.

For those upgrading from 0.3.5, check the README carefully, as there is now a useful distinction between :plt_apps and :plt_add_apps, and the options for plt_add_deps have changed.

I also found I have to add :mix and :eex to :plt_add_apps in order for Dialyxir to know about them.

0
Post #32
jeremyjh

jeremyjh OP

Hi thanks for checking it out and leaving the feedback Christopher. I meant to add a changes document to help with this, so thanks for the reminder. I will add a Wiki page tonight and plug it in the README.

Regarding :mix and :eex I was very conflicted on these - I considered continuing to include them whether they are specified or not. I believe the correct answer though (even outside of dialyxir requirements) is to add all your production run-time dependencies to your OTP application list; including core OTP and Elixir applications.

  def application do
    [applications: [:logger, :mix, :eex, :public_key]]
  end

edited: to clarify I mean adding run-time dependencies.

0
Post #33
michalmuskala

michalmuskala

Neither mix nor eex should be in the applications list. The applications list is used for runtime dependencies of the application - both mix and eex are not used at runtime - they are used exclusively at compile-time.

The exception is, of course, the runtime use of eex eval functions - in that case adding eex to the applications list is indeed the right thing to do.

3
Post #34
jeremyjh

jeremyjh OP

Yes of course - but Dialyzer warnings would only show up for runtime usage
in application code. One exception are Dev only runtime code - things like
the Phoenix live reloader - that will have runtime code in the Dev
environment only. So it should be added with :plt_add_apps only.

0
Post #35
hazardfn

hazardfn

Hey @jeremyjh,

We use dialyxir and we recently tried upgrading to 0.4.0 but sadly I don’t THINK we are able to use it in our current development workflow and I will explain why a little here:

How we develop:

All of our projects have a central makefile with common tasks in it (test, dialyzer, credo etc.), this central makefile runs EVERYTHING inside of a pre-defined docker image called teamname-dev.

Docker Image:

Inside this docker image we have everything we need for running the tasks mentioned above, meaning we install erlang and elixir and then archive/install things like credo and dialyxir. It is also here where we build our base PLT

As of 0.4.0 it seems you can no longer tell dialyxir to build a base PLT independent of a project - from what I can see it demands a mix file to be present but mix dialyzer.plt never did.

I like some of the additions and changes in 0.4.0 but unless there is a way to build a base PLT independent of a project I don’t think we can use it…

0
Post #36
jeremyjh

jeremyjh OP

The reason I made this change is I want to fully automate maintenance of the PLT and also discourage using a shared PLT between projects; it can lead to errors in analysis and/or constant changes to the PLT. You can still specify a :plt_file path though, if you do want to share a PLT file. I did think of the case people built it manually outside of a project but admit I did not consider your use case.

Would you use a shared PLT with all the application dependencies in it eventually, or you just want to build the core files ahead of time? I could make a task or arg that would just build the core files - or I could restore the dialyzer.plt task but I think it would need an argument passed to it telling the location of a PLT file to build, maybe even a list of applications to put into it.

0
Post #37
hazardfn

hazardfn

Yeah all we want to do when we build the docker image is to build the core files ahead of time :slight_smile:.

It would be great to have a way of doing this through dialyxir.

0
Post #38
jeremyjh

jeremyjh OP

Taking @michaelmuskala’s point I edited my original comment to clarify I only suggest to include production run-time dependencies in the :applications list. I also noted this in the upgrading wiki page .

0
Post #39
Eiji

Eiji

Hi @jeremyjh, can you help us at this topic?

0
Post #40