Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mix hex.build: Revisit basic metadata validations #916

Open
wojtekmach opened this issue Oct 12, 2021 · 4 comments
Open

mix hex.build: Revisit basic metadata validations #916

wojtekmach opened this issue Oct 12, 2021 · 4 comments

Comments

@wojtekmach
Copy link
Member

A brand new Mix project would trigger these warnings when executing mix hex.build:

** (Mix) Stopping package build due to errors.
Missing metadata fields: description, licenses, links

It is very easy to make the build pass by giving these "zero" values:

package: [
  licenses: [],
  links: %{},
  description: ""
]

which makes me think, should we either:

  1. add basic validations, licenses/links are non-empty lists, description is non-empty string
  2. make the "zero" values the defaults
  3. like 2, except empty licenses trigger a warning (https://github.com/hexpm/hex/pull/915/files#diff-06919f8ea819ec0528faa886d5f8ef7ff61d8564b9743a41d37636e286906c1bR199)

I think option 3 is the most appropriate. Thoughts?

@ericmj
Copy link
Member

ericmj commented Oct 13, 2021

I like they way it works currently because it pushes you in the direction of filling in the information but if you don't really want to you can add the empty values.

@supersimple
Copy link
Member

I think the links section is fine if empty, but we are warning (and soon will be raising for new packages) on missing licenses. The description does seem like something we'd want to pressure users into including. (none of this applies to private orgs.)

If we do validate the description more deeply, how? ie. If I just add 1 character, is that enough? why or why not?
Warning (vs raising) might not prevent people that really want to leave it empty, but I think takes what we do now (making sure the key exists) to the next logical level.

@ericmj
Copy link
Member

ericmj commented Nov 16, 2021

Should we have different validation depending on if you are publishing to an organization or a public package? How would that work for mix hex.build? Maybe we should move validation out of the build step and into the publish step by parsing the already built package in mix hex.publish?

@gustawlippa
Copy link

Hi, I stumbled upon this issue when trying to build a package locally. The documentation for hex.build (https://hexdocs.pm/hex/Mix.Tasks.Hex.Build.html) suggests that the description, links and license are not required. The docs could be updated to reflect the fact that some values (even if empty) have to be provided for these keys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants