Thanks for double checking @tsloughter. Putting this on hold for now.

priv/cacerts.pem isn't getting copied. Still figuring that out.

rebar, here, comes from certifi (in origin).

Hm... certifi doesn't pass the dialyzer test, so neither does rebar3. Lemme fix that.

rebar3, here, comes from certifi (in origin).

r3_certifi, here, comes from certifi (in origin).

Not sure about the name or location. But whatever changes there'll have to be changes to the vendoring script, too.

Moved below since certifi depends on parse_trans, not yet compiled at this moment (unless, that is, we want to also vendor parse_trans).

Prevents rebar3-based app.s from being limited to importing erlang-certifi due to a recent change in the path-management mechanism.

I'll comment on individual changes, where appropriate.

The new version of rebar3 handles dependency versions with an or (see https://github.com/erlang/rebar3/pull/2370), so dependencies relying on telemetry will be able to use ~> 0.4 or ~> 1.0.

(cc'ing @tsloughter to make sure that I haven't got ☝️ wrong, but it seems to be working with rebar3 3.14.4 in my tests).

We can safely mark 1.0.0 now!

Closes #69

Background

We have discussed in various issues moving to a "web auth flow" for authenticating with mix and rebar3 hex. I would like for the group to over the flow, discuss the pros and cons, and to formulate a time line if possible for moving to this. One big looming question for myself is : Will we all together stop password auth or will it be optional? This discussion is also in prep for completing the tasks in #11

Objective(s)

• [ ] Create an issue describing the approach, pros/cons, and strategy/timeline
• [ ] Enumerate that tasks that must be completed in order to start work on web auth
• [ ] Enumerate the tasks that must be completed to implement web auth flow.

Closed per today's discussion and #21

Background

Per #18 we have agreed to move forward with implementing a web auth token flow implemented in hex.pm and utilized by mix hex and rebar3_hex.

Tasks

The following tasks must be completed to resolve this issue.

• [ ] Add this project to the gsoc roster for 2021 (https://github.com/erlef/gsoc)
• [ ] Complete action item #11
• [ ] Create an issue on hexpm to align on flow and low level specifications
• [ ] Create an issue on hex_core to support the new api that will be described and detailed in the above task
• [ ] Create an issue on mix hex for working the new hex_core api offerings into to mix hex
• [ ] Create an issue on rebar3_hex for working the new hex_core api offerings into rebar3_hex
• [ ] Work with gsoc mentees and mentors to esolve all issues above

Related agenda items, issues, and pull requests.

Background

We recently adopted the setup-elixir github action. It may make sense to have a setup-erlang action to go with it. Currently and as far as I know there are two setup-erlang actions in the wild:

• https://github.com/gleam-lang/setup-erlang

• https://github.com/bajankristof/setup-erlang

I believe it makes sense to not only have a setup-erlang action within the erlef, but that it's important that both pull sources from the same place and provide the same argument interface.

Note: That one key difference between setup-elixir and gleam's setup-erlang is that the latter supports windows. It may be we don't want to take on this burden yet unless we have someone who is willing to help test and maintain.

Objective(s)

• [ ] create an erlef/setup-erlang action based off setup-elixir

Closing this per discussion today and the action item created #20

Background

As discussed per #12 we will create a setup-erlang action ala setup-elixir to aid the community in their CI/CD jobs.

Tasks

The following tasks must be completed to resolve this issue.

• [ ] Create a setup-erlang repository based off of setup-elixir
• [ ] Modify it so that it only brings in erlang
• [ ] Review existing similar actions and decide if there's anything within said actions that we want to incorporate not covered by setup-elixir base
• [ ] Review and test with existing erlang projects to ensure we have covered all bases.
• [ ] Work with the marketing working group to announce the new action

Related agenda items, issues, and pull requests.

Background

Tooling work is all that’s left for the docs folks, so we should be folding the group within this WG's efforts.

Tasks

• [x] Provide the list of people coming over
• [x] Sync with the board to announce and make the change official
• [x] Update the charter and invite lists to events

Related agenda items, issues, and pull requests.

• Feb 5 in the old agenda

Yeah, we talked ourselves to the same place :) I did take a look a the namespacing for Elixir though and having it under OpenTelemetry.Metrics would be fine and matches how Java is organizing theirs.

Some background to why I was thinking this was an actual issue.

I vaguely remember that when publishing the new package version itself (via rebar3 hex publish) it also said docs were published (@starbelly can you confirm? I might be entirely wrong here). That’s why I thought they should have already been published, and when trying publish them again and hitting my old Page not found cache I thought it “failed again”.

Again, sorry for the misreport.

@starbelly That’s great! Can I close this issue for now, or do you want to leave it open as a reminder?

Background

The EEF has applied once again to participate in the Google Summer of Code. Last year there were some ideas related to rebar3 and hexpm, so I wanted to check wether we were planning on proposing/mentoring any this year or not.

Objective(s)

• [ ] Discuss possible proposals this WG could make use of
  • [ ] And who would be up to mentor each
• [ ] Add them to the wiki of erlef/gsoc for students to pick up

I agree, this could be a neat proposal for GSoC. I was about to create an agenda item to discuss proposals within the WG, so it's great to already have one idea :)

Pre-Check

Building a new project fails

$ mv ~/.config/rebar3 ~/.config/rebar3.bak
$ rebar3 new app TestApp
$ cd TestApp
$ rebar3 compile
===> Error reading file rebar.config: 4: bad term

Environment

$ rebar3 report
===> Error reading file rebar.config: 4: bad term

$ rebar3 --version
rebar 3.14.4+build.4954.refe1b70e41 on Erlang/OTP 23 Erts 11.1.8

erl 
Erlang/OTP 23 [erts-11.1.8] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

$ lsb_release -a 
LSB Version:    n/a
Distributor ID: ManjaroLinux
Description:    Manjaro Linux
Release:        20.2.1
Codename:       Nibia

Current behaviour

Can't do anything , seems like a fundamental error across all actions in a project. I'm sure its something to do with my environment, I'll rupdate with test from somewhere else

Expected behaviour

Describe what you expected to happen.

yep, didn't notice the warning when I created the project