Cannot install a profiled library with `cabal install --lib -p pkgname`

[goldfirere]

Use case
I would like to experiment with performance characteristics of a few library functions. I am not building software to ship. I am just trying to learn more about Haskell. So I'd like to be able, say, to build an executable that depends on a few packages without needing to edit a .cabal file every time I change the set of dependencies. (Remember: the goal is quick experimentation!) A key requirement is that I need profiled libraries. The first one I wish to use is random. Read on to see what happens:

Describe the bug
I say cabal install --lib -p random. Cabal responds with Resolving dependencies... Up to date. Sounds encouraging. I can confirm that ghc Experiment.hs (which has import System.Random) works. But I want to say ghc Experiment.hs -prof. That does not work, with GHC saying I need profiled libraries. Note that I asked for profiled libraries with -p, above. I think: maybe my environment file has a stale entry. So I edit my env file to delete the line with rndm. I then cabal install --lib -p random again. The env file re-grows its rndm line... but the library still isn't profiled. I'm now pretty stuck.

Being stuck, but still eager to make progress, I try cabal v1-install -p random, remembering that such a command used to work brilliantly. After doing some building, I now get

Error while Error while updating world-file. : dieVerbatim: user error (cabal: Could not parse world file.
)

So that didn't work. I'm now completely stuck. I decide to do something other than learn more about Haskell for now.

To Reproduce
Included in the narrative above.

Expected behavior
I expected the first cabal install --lib -p random to update my env file with the correct entry to be able to do a profiled build depending on System.Random.

System information

• Operating system: macOS 11.6
• Cabal-3.6.2.0, cabal-install-3.6.2.0 ,ghc-8.10.7

[gbaz]

looks like a dup of #5982 and #7297 (and related to #7236)

Ideally this will all be resolved as part of revamping cabal v2-install functionality entirely as per #6481

(also note that this describes in the discussion that you can just delete the world file from your cabal directory if it was somehow created and is corrupt)

[goldfirere]

I understood #5982, #7297, and #7236 as being about executables, not libraries -- so I did not look closely at them (though I did find them in my searches before posting). Glad to see that there appears to be action at #6481 -- I'm eager for that feature.

For the record, the world file seems just fine -- I don't see how that could be the issue here. It says random -any.

If this ticket really is a dup of others, please close. I suppose the workaround is to create a .cabal and cabal.project file.

[fgaz]

Just the cabal.project should be enough iirc

[goldfirere]

That surprises me. I can have a cabal.project without a .cabal file? How would that work?

[fgaz]

It'd be a project with no local packages

[gbaz]

They were started about executables but the underlying issue is the same in all cases as far as we know from our sleuthing. Vis a vis world files, I'm just suggesting that if v1-anything is failing due to a world file error, its safe to delete the file, its vestigal and the entire half-implemented-never-working feature is removed in the next cabal release.

[ulysses4ever]

@fgaz I tried your suggestion about cabal.project without a local package (i.e. w/o <pkgname>.cabal), and it didn't work.

I have cabal.project with just profiling: true and I'm doing calling cabal-install ( 3.6.2.0):

cabal install -p --only-dependencies --lib --package-env=.  <space-separated list of packages>

(-p and --only-dependencies can be omitted with no change in the result)

cabal-install complains:

cabal: There is no <pkgname>.cabal package file or cabal.project file. To
build packages locally you need at minimum a <pkgname>.cabal file. You can use
'cabal init' to create one.

For non-trivial projects you will also want a cabal.project file in the root
directory of your project. This file lists the packages in your project and
all other build configuration. See the Cabal user guide for full details.

This is a strange message: it's either a logic bug (because I definitely do have cabal.project) or the message means and where it says or, and it's a documentation bug then.

I also tried to rename cabal.project into cabal.project.local, in that case I get another error message:

Warning: both implicit and explicit configuration is present.When using configuration(s) from <path to current directory>/cabal.project.local, the following errors occurred:
The package location glob './*.cabal' does not match any files or directories.

Any thoughts on this or how to get profiling libs without <pkgname>.cabal in general?

[phadej]

How much time is really "wasted" if you'd rather write a proper .cabal file (with cabal init or manually). Over few past years improvements to the rough edges in non-package/non-project cabal usage haven't made experience much smoother.

I.e. what can be done better or differently so people would just make ad-hoc packages&projects, instead of trying to use cabal-install as a "more clever" ghc-pkg (which cabal-install is not). IMHO that's just a echo of the past, if having a package setup would been always required, people would just do that. (And that's is my exprerience from other "mainstream" language ecosystems: use a package skeleton, even you don't intend distributing&publishing it).

[fgaz]

To answer @ulysses4ever question, you can work around that error by putting those packages (or even just a random package, like base) in extra-packages. Kinda ugly but it works. Note that due to #7297 (comment) a global profiling: True probably won't work and you'll have to apply it to every package explicitly (see the rest of #7297):

package *
  profiling: True

I do somewhat agree with @phadej though

[fgaz]

This is a strange message: it's either a logic bug (because I definitely do have cabal.project) or the message means and where it says or, and it's a documentation bug then.

Hmm, you're right... I think it should work so imo it's a bug. I've used this capability plenty of times with source-repository-package, and in that case it does work.

[goldfirere]

I.e. what can be done better or differently so people would just make ad-hoc packages&projects, instead of trying to use cabal-install as a "more clever" ghc-pkg (which cabal-install is not). IMHO that's just a echo of the past, if having a package setup would been always required, people would just do that. (And that's is my exprerience from other "mainstream" language ecosystems: use a package skeleton, even you don't intend distributing&publishing it).

I think this is a great question. Perhaps you're right that some of us (myself definitely included) are simply pre-conditioned to not want to make a project file. Here are some things that make writing a .cabal file annoying for me:

• I often don't know the dependencies of a throwaway Haskell file beforehand. It's already annoying to have to add (say) import Data.Text at the top of my file, but I see no way of avoiding this. Yet to have to also add a text dependency to a cabal file, figure out the right version bounds, and then restart HLS (which, I believe, does not react by default when a .cabal file is updated) is even more annoying.
• The annoyance is compounded manifold when I am doing a public demonstration -- such as in a classroom setting (a very realistic scenario from my recent past).
• .cabal files expose the wrong sorts of details for throwaway Haskell files: there's no executable, there's no exposed modules, and there's no testsuite. So in practice I would have to claim there's a library with some set of exposed modules, even when that's not really what I want.
• .cabal files are in want of a license file (among a few other requirements, I believe), not appropriate for the sort of situation I'm imagining.
• I want to be able to be very deliberate in how I invoke GHC, passing just certain flags, etc. That is, saying cabal repl to load my file is not the right answer, just in case I want to pass e.g. -ddump-tc-trace -dsuppress-var-kinds -fprint-explicit-kinds or something. I do not want to have to edit the .cabal file to get those flags to GHC. And it's annoying to have to say --ghc-options="..." or similar. GHC has its own interface: I want to use it.

Actually, those bullets aren't an answer to your question of "what would have to be different?". I suppose, for me, one way to move forward would be to allow some ~/.cabal/default.cabal file (say) that specifies default settings I wish to use for building. This could include a list of installed libraries, a default language, and even default extensions. Running cabal configure (or something) outside of any project could make sure that those libraries are available. It could produce a configuration file ~/.ghc/default-config (or something). Then, we could add a flag to GHC --config=... that loads the configuration stored in the file provided; saying --config (without the =) would use ~/.ghc/default-config. Or, somewhat equivalently, add two new top-level commands to cabal: cabal ghc and cabal ghci. These work by invoking ghc (respectively ghci) with the remainder of the arguments on the command-line, exactly as they are. The only difference between cabal ghc and ghc would be that the former would load the default config file (or, perhaps, the local project configuration if you're within a project directory).

In short: I, personally, am willing to maintain some kind of global .cabal-like file that specifies what dependencies I want generally available, and then contriving for a way to get GHC to see those settings. That would seem to fit in with the current cabal mindset, while solving some of the problems I've seen personally (and I've seen others echo).

[phadej]

, figure out the right version bounds,

.cabal files are in want of a license file (among a few other requirements, I believe), not appropriate for the sort of situation I'm imagining.

That is incorrect. Minimal .cabal file to get stuff going is no longer than:

cabal-version: 3.4
name: foo
version: 0

library
  build-depends: base, text, containers, deepseq, another-dependency
  exposed-modules: Foo

(Thing about exposed-modules as an argument which you would need to pass to GHC either way).

You should write the rest of the details if you want to publish the package, as you probably should to clean up the Haskell code as well.

I want to be able to be very deliberate in how I invoke GHC,

Add

{-# OPTIONS_GHC -ddump-tc-trace -dsuppress-var-kinds -fprint-explicit-kinds #-}

to the top your module.

[goldfirere]

The workflows you suggest still require me, for every directory I'm working in, to maintain separate .cabal files. When I add a dependency to each one, I'm sure some time will be spent building the libraries. This would not work in a teaching setting. And, in my GHC work, I frequently call GHC with different flags serially, in order to get different outputs, so editing the source file would be annoying. Maybe that's just me, and I'm too small a use case.

You asked what I would need in order to be more satisfied in my use of cabal. I answered, and you offered workarounds. I've been aware of workarounds to my problems for years, but they've never been satisfying. They still aren't.

[phadej]

The workflows you suggest still require me, for every directory ...'

What you mean by "maintain"? I had impression that you want to try something out, and then "forget" about that code. But if you expect to come back to these experiments days, weeks or months later, then writing .cabal file is a good time investment, isn't it? Dependencies listed which you used (even GHC flags in haskell or .cabal file), not all the libs you accumulated in your global environment (and maybe removed some if you had to start over).

I'm sure some time will be spent building the libraries.

Maybe, but somewhat unlikely: that's the "magic" of v2-build, the dependencies are in the global cache most of the time (especially when unrestricted and you don't cabal update often.

[ulysses4ever]

Two points here. I have been a happy user of (although mouthful) cabal install --lib --package-env=. for a while now, I really like it. It's very sad if I have to create two extra files when I want to get a profiling build (I am not quite sure if I can avoid cabal.project with profiling: true and use a command-line flag instead: I seem to remember that it's not possible but I may be wrong).

Second, to your question @phadej, I'd ask another question: do you see it reasonable to ask cabal-install to make the version and cabal-version into optional fields with some sensible defaults like 0 (for users like me or Richard, I suppose, any default would be sensible probably). Maybe name too? (Could be defaulted to the .cabal-file name, if it has to be non-empty). That would cut the bloat in half and make me much more susceptible to creating a package. Also, it would be nice to have a non-intrusive way to mute warnings about missing fields that cabal thinks are "really important" (if there are such warnings nowadays).

Some other random issues I have with cabal-install. My use cases are similar to Richard's but more often than not I need an executable that I can run and sometimes benchmark (e.g. with hyperfine). Using cabal run is not compatible with benchmarking: even when it doesn't suddenly decide to rebuild (and sometimes it does for no good reason I think) it still slowdowns things and pollutes output (unless I pass -v0? but I don't want to bother). Also, the executable is buried somewhere deep-deep under dist-newstyle -- this is very annoying. I think there's an issue to make it easier to get to the executable, but so far we have what we have. For example, Nix's feature with result in the current directly is rather ugly but super handy for my use cases.