Am Freitag, dem 29.03.2024 um 14:36 +0100 schrieb Francesco Ariis:

Hello Volker,

Il 29 marzo 2024 alle 14:26 Volker Wysk ha scritto:

...

Hi

I've migrated my HsShellScript library to Cabal 3.0 and now I get an error when I try to install it:

-----snip----- desktop /usr/local/src/hsshellscript $ cabal install --user Wrote tarball sdist to /usr/local/src/hsshellscript/dist-newstyle/sdist/hsshellscript-3.6.0.tar.gz Resolving dependencies... Error: cabal: Cannot build the executables in the package hsshellscript because it does not contain any executables. Check the .cabal file for the package and make sure that it properly declares the components that you expect. -----snip-----

If you are trying to install a library, use

cabal install --lib

and let us know if it worked as you expected

The install succeeds with "--lib". It had to be something stupid. It's been three years since I used cabal and meanwhile things look like they moved forward. There are other errors, but they don't look cabal-related. Thanks for your help. Volker

Hi, Brandon! That's some interesting information... Am Freitag, dem 29.03.2024 um 12:05 -0400 schrieb Brandon Allbery:

The short version is what Francesco said. The longer version is that with modern cabal (and stack), libraries are managed by cabal/stack and you don't normally install them directly. 

My case is this. I've written a new version of the HsShellScript library, and have uploaded it to Hackage. Now I wanted to use it to compile a script (written in Haskell). I though it wouldn't hurt to install it, so the new version is available. Now I understand that all I had to do is "cabal update", so the new version's on cabal's radar. The new version would then be downloaded and compiled automagically.

For the cases where you need a library to be available outside cabal's implicit sandboxing, there is `cabal install --lib`; but be aware that multiple versions of packages in the resulting environment may cause other build problems down the line, and it's on you to manage the environment file as needed. 

Hmm... I've googled what that "environment file" is: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-env... I certainly don't want to manage it by hand.

The proper way to work with libraries outside of a project is "cabal repl" or "stack ghci" as appropriate. For quick one-offs with cabal, you can use e.g. `cabal repl -b HsShellScript`. (I don't know the stack equivalent, sorry.)

What do you mean by "libraries outside of a project"? The library is one project by itself. I don't (?) have any libraries outside of projects (that I know of).

This whole rigmarole is intended to avoid situations where multiple versions of libraries are in ghc's environment and it picks inconsistent versions, leading to the old "cabal hell".

I don't want to go there!! ;-) Thanks for your explanation. Now the question is: How do I get back to the normal/regular state, without any library outside of a project? The next version of my library will sure come... Cheers, Volker

On Fri, Mar 29, 2024 at 9:50 AM Volker Wysk wrote:

...

Am Freitag, dem 29.03.2024 um 14:36 +0100 schrieb Francesco Ariis:

...

Hello Volker,

Il 29 marzo 2024 alle 14:26 Volker Wysk ha scritto:

...

Hi

I've migrated my HsShellScript library to Cabal 3.0 and now I get an error when I try to install it:

-----snip----- desktop /usr/local/src/hsshellscript $ cabal install --user Wrote tarball sdist to /usr/local/src/hsshellscript/dist-newstyle/sdist/hsshellscript- 3.6.0.tar.gz Resolving dependencies... Error: cabal: Cannot build the executables in the package hsshellscript because it does not contain any executables. Check the .cabal file for the package and make sure that it properly declares the components that you expect. -----snip-----

If you are trying to install a library, use

     cabal install --lib

and let us know if it worked as you expected

The install succeeds with "--lib". It had to be something stupid. It's been three years since I used cabal and meanwhile things look like they moved forward.

There are other errors, but they don't look cabal-related.

Thanks for your help.

Volker _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Am Freitag, dem 29.03.2024 um 13:48 -0400 schrieb Brandon Allbery:

On Fri, Mar 29, 2024 at 1:15 PM Volker Wysk wrote:

...

...

The proper way to work with libraries outside of a project is "cabal repl" or "stack ghci" as appropriate. For quick one-offs with cabal, you can use e.g. `cabal repl -b HsShellScript`. (I don't know the stack equivalent, sorry.)

What do you mean by "libraries outside of a project"? The library is one project by itself. I don't (?) have any libraries outside of projects (that I know of).

Cabal and stack are designed around the notion of projects, defined by a cabal file (or `package.yaml` if you use Hpack), `stack.yaml` for stack, optional `cabal.project` for cabal. Projects are sandboxed such that the package(s) in the project use consistent versions of all dependencies.

Neither tool handles use outside of a project well, although stack has a global configuration (whose use for this is deprecated iirc) and cabal uses ghc's environment files when requested. So something that isn't really intended for use as part of a project isn't well handled by either one.

Sounds complicated. I guess the best way to avoid trouble, is to do everything in projects and avoid code outside of projects.  

The biggest problem with both stack's global configuration and cabal's use of environment files is the need for manual management when new versions of packages are released: neither tool currently gives you any way to manage either, and having multiple versions of a package in either invites trouble. I can't speak for stack, but cabal devs are aware of the problem and considering how best to deal with it (see for example https://github.com/haskell/cabal/issues/9581).

You mean when you have code outside of projects, I guess. Multiple versions should be easily managed by cabal (or stack, which I don't know). I'm willing to subject myself to the way to do it, which is predefined by cabal (or stack), when in return, it all works without much hassle. I want to write code, not fight with the package management system. Happy hacking, Volker

The easiest way to work outside of a package is https://cabal.readthedocs.io/en/latest/getting-started.html#running-a-single.... Works pretty well, both in cabal run and cabal repl mode, and you can forget about any cabal *-install commands. Best regards, Andrew

On 30 Mar 2024, at 22:33, Henning Thielemann wrote:

On Sat, 30 Mar 2024, Volker Wysk wrote:

...

Am Freitag, dem 29.03.2024 um 13:48 -0400 schrieb Brandon Allbery:

...

Cabal and stack are designed around the notion of projects, defined by a cabal file (or `package.yaml` if you use Hpack), `stack.yaml` for stack, optional `cabal.project` for cabal. Projects are sandboxed such that the package(s) in the project use consistent versions of all dependencies. Neither tool handles use outside of a project well, although stack has a global configuration (whose use for this is deprecated iirc) and cabal uses ghc's environment files when requested. So something that isn't really intended for use as part of a project isn't well handled by either one.

Sounds complicated. I guess the best way to avoid trouble, is to do everything in projects and avoid code outside of projects.

You can easily turn code outside of a project into code inside a project, by adding something to the 'packages' field in cabal.project or add a separate 'source-repository-package' entry in the cabal.project.

Or you stick to 'cabal v1-install'. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.