Add support for convenience libraries

[bos]

(Imported from Trac #276, reported by rl on 2008-05-09)

I'd like to have a package with several binaries which all use a convenience library included in that same package. The convenience library should NOT be installed. For this to work, Cabal needs two things. Firstly, it must allow dependencies within a package such that I could describe the library and have the binaries depend on it. Secondly, it should have an "installable" flag, similar to "buildable". A thing that's not installable would be built but not installed. The same mechanism could be used for package-internal tools.

[bos]

(Imported comment by @dcoutts on 2008-05-09)

There is the constraint that there be at most one installable library so I'm not sure a bool flag is quite right.

[bos]

(Imported comment by @dcoutts on 2008-05-09)

This would mean that the lib would always have to be built statically even if the user requests dynamic libs.

So this feature mainly depends on the ability to use build-depends: on a lib defined within the same package (whether that lib is to be installed or not). Similarly for build-tools.

This would also solve ticket #89.

[BardurArantsson]

Last comment 2008(!). And is this even reasonably feasible, given the apparent complexity wrt. static vs. dynamic[1]? "Create an app-specific library" does not seem too onerous a requirement, especially if #2631 comes to fruition.

[1] I don't know if "static" here includes C libraries, but if it does... glibc simply cannot be statically linked in any case.

[BardurArantsson]

IOW: Close.

[dcoutts]

No I think this is quite feasible and indeed still a good idea.

[BardurArantsson]

Is anyone (realistically) going to implement it? I'm voting for "WONTFIX-UNLESS-SOMEONE-STEPS-UP".

(I don't necessarily think it's a bad idea, but issue trackers of GitHub's caliber aren't meant for "wishlist" items.)

EDIT: Btw, this has been open since 2008 and nobody showed up to implement during all that time. That should tell you something. Please just close this.

[BartMassey]

@BardurArantsson: Why the eagerness to get a valid issue closed? Maybe someone will come along five years from now looking for something to do and find this. Let's not make it harder to find by closing it.

I'm not sure why you think wishlist items don't belong in the issue tracker?

[martinvlk]

I think even closed issues remain in the tracker, and can be found so this is not a reason to keep it open..

[BartMassey]

@Martinvik: People looking for something to work on rarely look in the closed issues.

[BardurArantsson]

@BartMassey The likelihood of anyone randomly dropping by and picking this up is nil for all practical purposes. I refer to the fact that this has been open since 2008.

Meanwhile, every such item is causes a certain (small) amount of wasted time every time any one browses through the issue list. Given the above, I believe it's better to just close such issues.

(I have a whole rant about why bug trackers are not the place for wishlist items in general, but I'll spare you :) .)

[BardurArantsson]

Btw, my half-baked theory on why next to no drop-by contributors do wishlist items is that people tend to want to scratch their own itch -- in which case it won't matter if there's an open issue. (Unless they're just trying to pad their own résumé, in which case they might as well work on something that matters to more people. There's plenty of more important issues to go round.)

[phadej]

I'd rather add label pr welcome, to indicate that it's ok to implement this or that feature request and submit the pr.

That said, it's obvious that I'd only close issues when there is real need (obsolete, or fixed / implemented / or clearly wontfix). There are labels, which could be used to classify issues. IMHO enchancement and milestone: ⊥ do the job quite well. The pr welcome -label might communicate it even better. No need to close with the message "re-open if needed".

There are people, who want to contribute, but have no idea about where to start or what to do, and what is easy and what's not. The infrastructure hackathon is one of the empirical proofs of that.

And returning to this feature: it might be easy task: as you don't need to register/copy the library bits, only executable(s). IIRC there was an issue related to that (more component oriented approach in cabal-install), which could solve this trivially.

[BardurArantsson]

The problem is that if we don't have a clear guideline for exactly how to proceed on any given issue then "pr welcome" or "easy" issues are, I'd argue, even worse than useless because people will just dive in and immediately get discouraged because these things often unfortunately aren't easy due to the state of the cabal-install code base. Either that or we need some person who's willing to be designated "mentor" on said issue and who can help guide the person through. (Similar to a hackathon.) I don't deny that these people who want to help exist -- but I think there are more useful issues they could be working on! (See also below.)

The problem with labels is that they have no semantics associated with them by GH Issues... and the project doesn't seem to have any either? (Didn't do a particularly thorough search, but I couldn't find any description of what any of the labels in here actually mean.) I also have a whole rant about GH Issues... :).

I'm not necessarily saying that wishlist items should automatically be discarded/closed, but wishlist items with no action since 2008? C'mon, now! That's obviously a wishlist item that no more than 1+\epsilon people care about. (In general, I think there must be some sort of "deadline" for wishlist items, unless we're talking rare cases of wishlist items which are showing clear progress towards being solved.)

Btw, thanks for the description of a possible solution for this concrete issue. THIS is what should be front-and-center (i.e. in the issue description) for any "easy" or "pr welcome" type issue.

(This is a bit of side -- but related -- issue, but the project as a whole could definitely do better on the "pr welcome" front -- it certainly doesn't appear like PRs are particularly welcome at the moment. There are a lot of lingering PRs in the queue, many probably obsolete or not which will have to be redone because master has moved on... not encouraging for outsiders :/. I know people are doing their best, but... I think something needs to change.)

EDIT: Sorry, that turned out longer than I intended.