Skip to content

Conversation

@maennchen
Copy link
Contributor

Filter out dependencies marked as optional in Hex package metadata. Rebar3 does not support optional dependencies, so they should not be fetched or compiled. This fixes issues where optional Mix-only transitive dependencies would cause build failures.

BumpPACKAGE_INDEX_VERSION to invalidate existing caches.

I have verified the change with the purl package locally.

Fixes #2977

Filter out dependencies marked as optional in Hex package metadata.
Rebar3 does not support optional dependencies, so they should not be
fetched or compiled. This fixes issues where optional Mix-only
transitive dependencies would cause build failures.

Bump PACKAGE_INDEX_VERSION to invalidate existing caches.

Fixes erlang#2977
-define(DEFAULT_COMPILER_SOURCE_FORMAT, relative).
-define(DEFAULT_COMPILER_ERROR_FORMAT, rich). % 'minimal' for default values as of 3.23.0 and earlier
-define(PACKAGE_INDEX_VERSION, 6).
-define(PACKAGE_INDEX_VERSION, 7).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason we need to bump the package index version? I believe the disk format is the same, the question is just whether we want to refresh what we keep inside or outside of it? Arguably we should be able to reuse the same package version but trigger a fresh build.

I guess it would be for consistency (everyone refreshes their snapshots, behavior is the same across all similar rebar3 builds?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ferd Yes, the format is the same, but we might calculate the requirements differently.

But this whole thing is probably more of an edge case. We can also keep the version and tell people to clear the cache if they run into trouble.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah to get consistent behavior I think it'd be fine bumping the version. It might mess with some cached images for builds that will need a refresh (if any) but I'd rather do that than seeing people get inconsistent builds (and lock files) from the same rebar3 version based on past fetch history.

Copy link
Collaborator

@ferd ferd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging this, will let it simmer a while before cutting a build, letting people find issues if any.

@ferd ferd merged commit 4277af3 into erlang:main Jan 8, 2026
6 checks passed
@maennchen maennchen deleted the jm/optional_reject branch January 8, 2026 05:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Rebar3 tries to compile Mix-only optional transitive dependencies

2 participants