v7.0.0

[starbelly]

Version 7

This issue enumerates everything that needs to be changed in order to be aligned with mix/hex interface and behavior that would be considered a breaking change. Updating docs on rebar3.org is implicit for each item and required.

Breaking changes

• [x] add docs arg support on publish (i.e., rebar3 hex publish docs)

• [x] add package arg on publish task (i.e., rebar3 hex publish package)

• [x] remove --without-docs option on publish

• [x] remove --package option that goes with --revert

• [x] add --app switch on publish task for specifying a single app to in an umbrella for all publish sub tasks.

• [x] add --docs-dir option on publish task (unique to rebar3_hex)

• [x] support --dry-run for publishing in general

• [x] Merge existing docs code into publish task and remove umbrella related code

• [x] Merge existing revert task code into publish task

• [x] Update cut task to work with publish task changes.

• [x] re-work repo task to be aligned with mix hex organization

• [x] move key task code to user task and remove key task

• [x] add unretire support on rebar3_hex_retire

• [x] change message argument to a switch in rebar3_hex_retire

• [x] - add a build task ( see https://hexdocs.pm/hex/Mix.Tasks.Hex.Build.html#content)

Tasks that should be completed before release

• [x] Add docs
• [x] QA

Internal changes that do not have to happen at any particular stage

The following items are to be completed prior to additive changes to ease contributions by others. These need to be further defined (properly defined) in their own respective issues or draft PR(s).

• vendor in hex_core
• refactor all existing task modules to follow a common pattern (rebar3_hex_key is a prototype)
• refactor existing functions into smaller functions where applicable, we have a lot of functions that are simply too large.
• expose or move all functions (which also means making new functions) that do not have side effects in modules / into new modules and test them directly
  • per the above do as little in rebar3_hex_integration_SUITE as possible, it should be limited to what can not be tested any other way
• contributing / developer docs , some what internal, but should be made available on rebar3_hex repo

Additive changes - post ver 7.0.0 release

The following items are added here for enumeration purposes. An issue is to be created for each item. These are prioritized and should be completed in order. Items that are nice-to-have are just that, they are not crucial or critical in any form.

• add a config task (existing issue https://github.com/tsloughter/rebar3_hex/issues/208)

  • This includes copying all the config functions from rebar_hex_repos in in rebar3 and probably removing the update* and remove* functions from rebar3 itself as they were only put their to facilitate rebar3_hex

• add diagnostics ala rebar3

• improve help messages, similar to what we output for publish but we can do better there as well.

• add support for exclude_patterns configuration per #233

• new docs task becomes a task to fetching and opening docs - not used for publishing

• add a new repo provider ala mix hex.repo

• add an outdated task (see https://hexdocs.pm/hex/Mix.Tasks.Hex.Outdated.html#content)

• add package task used to fetch packages or diff them (see https://hexdocs.pm/hex/Mix.Tasks.Hex.Package.html#content) (nice-to-have)

• add an audit task (see https://hexdocs.pm/hex/Mix.Tasks.Hex.Audit.html#content) (nice-to-have)

• add an info task (see https://hexdocs.pm/hex/Mix.Tasks.Hex.Info.html#content) (nice-to-have)

• add a registry task (see https://hexdocs.pm/hex/Mix.Tasks.Hex.Registry.html#content) (nice to have)

• add a sponsor task (see https://hexdocs.pm/hex/Mix.Tasks.Hex.Sponsor.html#content) (nice-to-have)

[starbelly]

Really need @tsloughter to comment on removal of cut

[starbelly]

Right per the last B&P meeting (May the 4th be with you) we will remove cut as part of V7. We can re-introduce it again later, but it's probably best off being a separate plugin.

[tsloughter]

I'm completely opposed to removing cut. What is the purpose of removal? What is gained?

[paulo-ferraz-oliveira]

If this is restored, could an option exist to not include the v prefix in the tags?

[tsloughter]

Sure.

[starbelly]

@tsloughter The purpose was less to support. As you saw had tried to get feedback from you and not just via this issue, but it's understandable to me why you weren't able to response 👶 So all that said, my feelings on this aren't strong enough, and thus we can just put it back.

[starbelly]

re-work repo task to be aligned with mix hex

This task doesn't actually have to be done for initial v7. Simply, we can rename repos task to org and adjust the interface to align with mix hex (mostly).

The repos task is mix hex is for updating config, which is very useful, but I would opt to do it post v7.

Likewise, the docs task isn't required for v7 initial release either, mix hex doesn't use the docs task for generating. For rebar3_hex generating docs can currently be accomplished with on the publish task with the --dry-run switch. There's a bit to think about, regardless I will move the docs task into "can be done later" section and update the one for repos.

[starbelly]

@tsloughter before I change the repos task to be called organization, are you ok with that? I think it's fine myself, calling it organization doesn't imply that it has to be something on hexpm IMO.

[tsloughter]

Why would it be called organization if its for repos?

[starbelly]

@tsloughter tbh, I don't have strong feelings here... Organization is a repo. The goal is to align with mix hex's api as much as possible, so that would be the argument for renaming it... that said, I don't think we have to align on every single thing either.

Edit:

I guess your train of thought is a repo can be anything, not just hexpm. That would make sense to me. In that case it would be redundant perhaps to even have an organization provider considering repo provides all that. I think it's fine then to keep repo which obviates an organization provider, we just need to doc that if you're looking for an organization task, then repo is what you want.

Edit:

Organization is a repo.

That's not really true actually, but we treat them as repositories (sorta) in rebar3_hex, at least as far as stored configuration goes.

[starbelly]

@tsloughter Here's one other aspect to consider when it comes to the name of the provider... right now, it's only good for organizations. Whether it's hexpm or your own self-hosted instance of hex, it's still only good for orgs. Specifically, you can't authenticate to the main repository (i.e., hexpm) using this command as it requires you to be authenticated as a user.

Basically, what we'll end up saying in the documentation, "This provider is only useful for authenticating and managing organization repositories" and at that point, I just don't think it makes any sense to call it repo.

But maybe there's plans to expand that some how later down the road?

[tsloughter]

oh, just the repo provider name, that should be fine.