haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.62k stars 697 forks source link

cabal install from a url doesn't work for libraries #8335

Open yaxu opened 2 years ago

yaxu commented 2 years ago

Describe the bug cabal install with the --lib flag and a URL doesn't work, it tries to install an executable instead. This makes testing candidate releases more difficult.

To Reproduce Steps to reproduce the behavior:

alex@pop-os:~$ cabal install --lib https://hackage.haskell.org/package/tidal-1.9.0/candidate/tidal-1.9.0.tar.gz
Downloading
https://hackage.haskell.org/package/tidal-1.9.0/candidate/tidal-1.9.0.tar.gz
Resolving dependencies...
cabal: Cannot build all the executables in the project because none of the
packages contain any executables. Check the .cabal files for the packages and
make sure that they properly declare the components that you expect.

System information

Mikolaj commented 2 years ago

Thank you for the report. I guess cabal v1-install works fine? How about cabal-env (at https://github.com/phadej/cabal-extras), which is intended to replace --lib at some point (there is a ticket about that somewhere)?

yaxu commented 2 years ago

Yes cabal v1-install works great for me, as long as I never use v2-install.

cabal-env doesn't seem to support URLs:

alex@pop-os:~/src/cabal-extras/cabal-env$ cabal-env  https://hackage.haskell.org/package/tidal-1.9.0/candidate/tidal-1.9.0.tar.gz
"<eitherParsec>" (line 1, column 7):
unexpected "/"
expecting "{"

Usage: cabal-env [-w|--with-compiler ARG] [-n|--name ARG] [-a|--any] 
                 [-v|--verbose] [-d|--dry-run] 
                 [(-t|--transitive) | --no-transitive] [PKG...] [--local] 
                 [(-i|--install) | (-s|--show) | (-l|--list) | --hide] 
                 [-W warning | --trace-process | --color-auto | --no-color | 
                   --color] [--version]

  Manage package-enviroments
Mikolaj commented 2 years ago

cabal-env doesn't seem to support URLs

Oh, so that's one more thing to implement before it can replace --lib. I guess we can start by fixing that in --lib, since it sound like a bug, not necessary missing big chunk of code.

jneira commented 2 years ago

the non trivial but doable workaround could be cabal get http://path/to/candidate/foo-x.y.z.tar && cd foo-x.y.z && cabal install --lib --package-env=. @yaxu maybe would it work for you?

jneira commented 2 years ago

for completeness the issue about replacing install lib would be #6481

yaxu commented 2 years ago

the non trivial but doable workaround could be cabal get http://path/to/candidate/foo-x.y.z.tar && cd foo-x.y.z && cabal install --lib --package-env=. @yaxu maybe would it work for you?

I'm happy installing from a folder but am looking for an easy one-liner for users of the tidal package to try out prereleases. Most such users are unfamiliar with the commandline, and could be on windows, macos or linux. Generally the v2- commands are unreliable for such people, who easily end up with a broken system that can take them days to sort out if they ever manage it.. Even if they're attempting something as simple as upgrading tidal on an otherwise working system.

Mikolaj commented 2 years ago

Right, that's a shame.

Generally the v2- commands are unreliable for such people, who easily end up with a broken system that can take them days to sort out if they ever manage it..

Doesn't the good old wiping out of ~/.cabal/store and of the local working directory always work?

yaxu commented 2 years ago

Deleting .cabal and .ghc is common advice to start again from a clean slate, but again many users will be unfamiliar with the commandline and the concept of hidden files, getting such people to run an rm -rf command is stressful and extremely dangerous (add a space between . and cabal? whoops), and the location on windows machines is elsewhere.

Mikolaj commented 2 years ago

Deleting .cabal and .ghc is common advice to start again from a clean slate

v2- has the advantage that it's only .cabal now. However, if I'm not mistaken, you also need to remove .ghc.environment* from your current working directory.

but again many users will be unfamiliar with the commandline

Perhaps they would be more comfortable with a file manager default to that OS if given a single path to remove?

and the concept of hidden files

That's indeed a snag in v2- due to the .ghc.environment* files. I wonder if the following instruction would be better: "create a new working directory, ~move~ copy over all your important files, keep the old directory as a backup or remove it".

Anyway, a shame indeed that we need to work on workarounds. instead of testing a fix. Where did https://github.com/haskell/cabal/issues/6481 stall exactly? Users not satisfied with the proposed functionality or nobody willing to implement it (any more)? IIRC there was a plan to test cabal-env before porting this to cabal but, I guess, asking end users to install yet another tool is not an option?

yaxu commented 2 years ago

Perhaps they would be more comfortable with a file manager default to that OS if given a single path to remove?

Yes although getting the file manager to show hidden folders is not straightforward either.

Note that tidal users don't generally use any other libraries so only need the one 'global' environment.

Where did https://github.com/haskell/cabal/issues/6481 stall exactly?

I'm not sure, maybe just free/open source work overload. I'm very grateful for any work on this.

Mikolaj commented 2 years ago

Yes although getting the file manager to show hidden folders is not straightforward either.

Oh, I didn't know that ~/.cabal is called .cabal on Windows as well. I suspected it's rather some /Users/foo/AppsData/cabal. No clue about OSX, either. Or can a folder be "hidden" and not start with a dot?

Mikolaj commented 2 years ago

Apologies, I linked to here from an unrelated ticket due to off-by-one error. :)

yaxu commented 2 years ago

I'm a linux person myself so am hazy on the details of other systems as well..

fgaz commented 2 years ago

I'm surprised that it even installs the executable in the first place, given #7360

fgaz commented 2 years ago

Where did https://github.com/haskell/cabal/issues/6481 stall exactly? Users not satisfied with the proposed functionality or nobody willing to implement it (any more)?

The latter. Nobody offered to implement it yet. I would if I had the spare time (or if someone paid me to do it ;) ) There's also the issue of cabal-env being under copyleft, so we'd need either permission from phadej to port it to cabal or a clean room implementation

jneira commented 2 years ago

I'm happy installing from a folder but am looking for an easy one-liner for users of the tidal package to try out prereleases. Most such users are unfamiliar with the commandline, and could be on windows, macos or linux.

well, the workaround is a "one-liner" too, only longer 😝

mainly joking, but imo if you gives an easy way to copy the one liner, I think the size will not matter so much (take a look for the "one-liner" for installing ghcup and people seems to be happy with)

Generally the v2- commands are unreliable for such people, who easily end up with a broken system that can take them days to sort out if they ever manage it.. Even if they're attempting something as simple as upgrading tidal on an otherwise working system.

I am afraid that drawback will be shared by a hypothetical working cabal install foo.tar --lib Moreover v1 commands were also fragile for packages having dependencies, and most of them has them (although tidal seems to be an exception)

If you want install globally the lib you should remove the --package-env=. from my example.

yaxu commented 2 years ago

well, the workaround is a "one-liner" too, only longer stuck_out_tongue_closed_eyes

Compatibility across windows and unix is tricky, though.

jneira commented 2 years ago

I am developing on windows and that one liner works in raw cmd. It also works on linux sh. powershell would need replace && with ;