Hacker News Reader

Comment by enriquto | Hacker News Reader

I would appreciate a small section on the README file that explains how to compile the program, what are the requirements (e.g., what debian packages to install), and a minimal cli use case.

Also, running "make" prints a daunting 96 lines of text of which the last 50 (the ones that you get to see) are mostly useless. If I run "make build" it starts to download stuff from the internet, which I find extremely impolite, as I already downloaded the source code. What is the point of not including all the neeedded source code in the source distribution?

View on HN

Thanks for the feedback, I'll take a look at the README. Does http://hledger.org/download, prominently linked on the front page, have the right info ? My intention was for you to find that, so I'm curious how you travelled from this HN post to the README.

PS: "make" prints its help, a summary of all targets. I agree it's more than a screenful and will need to be viewed with a pager (I'm used to viewing things in an emacs shell). The Makefile is assumed to be used mainly by contributors and does a lot. What would you recommend "make" to do ?

Haskell is a bit rare and so are its libraries rarely installed on systems. I can't remember, as arch has a proper package and I built hledger only once on a different system, but those downloads might be just libraries.

Whatever. Either they are dependencies that are required to be installed beforehand (just like a haskel compiler is required), or they are included in the source code distribution. Downloading them at compile time is very strange, and in my eyes unacceptable.

While I do see that this might be valuable, I find the argument strange and it makes me wonder in which area you work that this is so alien to you.

I've generally come to expect that any software I download and try to build might, through a package manager, pull in additional dependencies (rust, Haskell, scala/Java/closure,...). The only real outliers here seem to be C and C++, of the ones I've worked with.

It's not different from what pip install or gem install do by default.

A mature Haskell project such as hledger has probably a few hundred of transitive dependencies, so you won't be able to install them individually by hand. You might try to figure whether each of them is packaged by your distribution (unlikely, unless hledger itself is packaged), but that's not a typical path — just don't use make in that case.

> It's not different from what pip install or gem install do by default.

Pip installing required packages is alright. But I expect setup.py to NOT call pip install by itself.

> A mature Haskell project such as hledger has probably a few hundred of transitive dependencies

That's horrifying!

Maybe so. :) It's also code reuse, actually working, and quite common for non-trivial end-user apps, particularly in the Haskell world. I'm not sure what kind of software you're used to. It's interesting to imagine how hledger would be different if I wrote everything myself, but I have to think it would be far less further along.

Thanks for your answer! I'm used to mostly C, C++ and Python projects. In the worst cases, when I download and compile a program I have to install two or three dependencies, and it is OK if I do it by hand. For an eminently unix-friendly program like hledger I was expecting a similar ease of installation (i.e., I have an arbitrary haskell compiler and I can just compile the program running "make"). But I was surprised that this is not the case; obviously the traditions of the haskell community are different. Yet, it seems very difficult to install this program in a controlled environment without internet access.

Thanks. Well if we assume "arbitrary haskell compiler" means GHC and stack (or just stack), "make install" will compile it. But yes, there will be much downloading, unless you just happen to have all those haskell libs cached locally from previous builds.

"stack install hledger" would compile just the command line tool (not the curses & web tools), so less downloading.

For end-users who want minimum downloading/building, we recommend one of the binary packages on the download page (nix, docker, homebrew, windows/wine), but that's not you I think.

Almost every widely used modern language has a package manager ecosystem that does exactly this. How is that very strange? There are well debated pros and cons with the use of package managers of course, but to call it strange is, well, strange. :)

I'm used to Python's "pip install", but I have never seen it called from inside the "setup.py" of a particular program.

Reply on news.ycombinator.com