Rebar.lock doesn't include dependencies from prod profile?

Questions / Help
1

I know that the locking logic in rebar3 is kinda complex, but it seems like a massive oversight not to lock thing that end up in the release.

Is there any way to get this to happen?

1 Like
2

Hardened rebar.lock is the most stupid part of the rebar3. Like the ‘requirements’ in hex_metadata.config

We are forced to live with this JS-like nonsense.

3

In which case are dependencies not included? Do you have an example?

4

Putting the deps inside the prod profile.

5

I’ve never used Rebar like that. I always put the dependencies on the top level (i.e. in the implicit default profile).

Rebar does have the as <profile> meta task but unfortunately rebar3 as prod lock (or unlock) doesn’t seem to use the dependencies in the prod profile.

For now I think your only option is to move anything that is “prod” to the top level list (which IMO makes sense).

6

If I understand it correctly prod is also just a convention, not really an official profile in Rebar. It’s even explained exactly for your use case in the last notice in this section of the documentation.

7

Except that I don’t want these dependencies except at (released, deployed, production) runtime. They’re various observability/metrics things that don’t work locally. I was hoping to avoid pulling them when they’re not gonna be used.

documentation

Sigh. OK.

The problem with that suggestion is that the relx block needs to go inside the prod profile, otherwise Rebar3 shell tries to run applications from relx block?

I think rebar4 needs to have better profile management, with an explicitly supported release, prod, production profile or whatever.

8

another way to avoid ‘rebar3 shell’ starting applications from the release in relx is to configure the list of apps to start:

{shell, [{apps, [App]}]}.

1 Like
9

Thanks for reminding me of another oversight in rebar3 I should make sure those doing rebar4 are aware of and may be able to address :slight_smile:

10

So a release profile that is used when you run rebar3 release? The same as we run in the test profile when running rebar3 ct?

11

If you think that can be made to work in an unsurprising way. It’s probably what most people expect, since other language ecosystems (off the top of my head: Rust, .NET) have an explicit distinction between development/debug and production/release.

12

Oh, well release isn’t meant only to be production. It has a dev mode for building with symlinks for example.

Compared to Rust it is more like how you get a binary built into the default profile unless you run the build with --release.

Maybe the issue is relx modes don’t tell rebar3 anything about deps. So you may have relx running in {dev_mode, false} but it doesn’t mean your rebar3 prod deps are in use.