leptonyu / odpic-raw

Haskell raw bindings to Oracle ODPI-C Library
BSD 3-Clause "New" or "Revised" License
18 stars 5 forks source link

Cabal file #8

Closed mulderr closed 6 years ago

mulderr commented 6 years ago

Hi again,

first of thank you for the latest changes! However, if I can nitpick a bit more, please keep the cabal file in the project. Among other things it's used by Nix tools to automatically create expressions. Removing it means odpic-raw will be broken on NixOS.

BTW. since odpic is now in nixpkgs, on master you can get a working shell with odpic-raw using:

nix run '(import <nixpkgs> {}).haskellPackages.ghcWithPackages(ps: [ ps.odpic-raw ])'
mulderr commented 6 years ago

Ah, I think cabal2nix may be handling this automatically these days. Not sure though. Will verify later today.

mulderr commented 6 years ago

After examining this closer, if that's ok, I would suggest keeping the hpack generated cabal file in the repo. As does hpack itself.

Otherwise the build depends on the version of hpack the user has available on the build system. This is not great for Nix and it's reproducible builds. Especially that package.yaml does not specify the minimal version of hpack to be used.

Depending on how I run hpack on my machine it will either fail altogether or ignore the defaults field because NixOS 18.03 currently has 0.21.2 and support for local files in defaults was added in 0.26.

leptonyu commented 6 years ago

Hi, I don't use nix, so I'm not sure the compatible of nix and hpack. How about to change defaults as follows?

  github: leptonyu/odpic-raw
  ref: master
  path: defaults.yaml
leptonyu commented 6 years ago

Another solution may be that I can keep the odpic-raw.cabal file in the project.

mulderr commented 6 years ago

I'd vote for keeping the generated cabal file in the project.

This time we can fix things by using a different value for defaults but that may not always be the case. Also, does hackage automatically handle hpack? Don't you need to generate the file anyway before you upload? Even if it does handle hpack automatically than I guess my previous point stands - it's not reliable because it may be using a different version of hpack than you intended.

leptonyu commented 6 years ago

Hackage do not known exists of hpack, only odpic-raw.cabal will upload to hackage. I can build succeed by stack --nix build locally.

so nix use which source to build odpic-raw? hackage source or github?

leptonyu commented 6 years ago

odpic-raw hackage source

mulderr commented 6 years ago

Nix will normally use the version on hackage. Which specific one depends on the version of nixpkgs. List of hackage packages for Nix is generated from an LTS snapshot AFAIK. But nix does not use stack. It needs a .cabal file one way or another to generate the expression.

However, it's very nice to be able to override that and point it to github when you're working on something or need a newer version than is in the nixpkgs you're using. Also a lot of people like to pin dependencies in their projects to specific commits on github. In that case cabal2nix may try to run hpack if it does not find .cabal but there is no guarantee it will use a correct version of hpack and that can cause problems.

leptonyu commented 6 years ago

@mulderr ok, let's keep the .cabal file.

leptonyu commented 6 years ago

@mulderr how to publish a haskell package to nix? Do I have to trigger something?

mulderr commented 6 years ago

Thanks again for a quick solution!

Re nix, the only thing you need to do as a package maintainer is to upload to hackage. The rest happens automatically or is taken care of by nixpkgs contributors.

There is usually some delay until a package uploaded to hackage appears in nixpkgs. For example as of right now the version in nixpkgs is still 0.2.1 and hackage already has 0.3.0. But it should soon be updated. Commit history suggets it's updated every couple days at least.