Need endorsements to upload yamlscript package to hackage

Learn
1

Hi there.

I have a Haskell package that I am ready to upload to Hackage candidates, but I need 2 endorsements: Endorse user | Hackage

The package is a haskell binding to YAMLScript’s libys.so shared library.
See: YS Binding Libraries - YS — YAML Done Wisely

Can I get a couple endorsements here?

3 Likes
2

BTW, Is this the right place to ask for an endorsement or do I need to do something else?

2 Likes
3

Yes it is, welcome to Haskell Discourse!

3 Likes
4

I received my endorsements (thank you to whomever) and uploaded my first package (after checking it with candidates) yamlscript: Haskell bindings for YAMLScript

Cheers

5

Welcome. It’s good to see that you got your package uploaded. The other way to get approved as an uploader is to write to hackage-trustees@haskell.org, and the approving Trustee will often send the following advice:

Here are a few things to keep in mind when uploading to Hackage that help keep the ecosystem working reliably for everyone:

  1. Hackage is intended to be a permanent record. Therefore uploads cannot be changed or removed.
  2. Only upload things that work, are useful to other people, and that you intend to maintain.
  3. Use cabal gen-bounds to put PVP-compliant version bounds (lower AND upper) on ALL your unique dependencies so your package will still be buildable years down the road. One important thing to note is that you only need to include version bounds once. For example, if you depend on the same package in your library and your test suite, you only need to put the version bounds for that dependency in one place. This keeps the dependency bounds information DRY.
  4. Package candidates CAN be changed, so use them to test things out and get everything right before you publish permanently to the main index.

I had a look at your package, and the .cabal file is not including PVP-compliant upper bounds: under the PVP, the first two components of a version number denote the major version, so a bound like text >=2.0.0.0 && <3 permits breaking changes from text ^>= 2.1 (which it might work with) and text ^>= 2.2 (which is an impossible promise, as that package hasn’t been released yet). This can and should be fixed with a metadata revision, so cabal won’t invent incorrect build plans if a package you depend on breaks backwards compatibility.

The .cabal also file makes reference to a Makefile that isn’t present in the source tarball. I don’t know much about the YamlScript universe but my recommendation is to let the system package manager provide native dependencies, and use pkgconfig-depends: to declare that your package depends on them.

I’m writing this here so other people looking for endorsements might see the standard advice, and because the Hackage package has no pointer to the forge you’re using for this project. (Normally, the homepage: field is used for the package homepage, not the overarching project homepage.) I think you should use a source-repository declaration to identify the upstream source.

Again, welcome, and best of luck with your project.

3 Likes
6

Thanks for the feedback.
I’ll look into these issues soon.

BTW, shouldn’t cabal check flag the issues you mentioned?

Also in your version bounds examples you used 2.0.0.0 and 2.1 but my version was 0.2.1.0.
Not sure if you noticed that correctly…

7

No idea. It certainly flags some issues but I would be pleasantly surprised if it is completely thorough. Possibly worth filing issues if it doesn’t?

That is in reference to your yamlscript package’s dependency on the text package, not your package’s version itself.

1 Like