Open yaxu opened 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)?
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
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.
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?
for completeness the issue about replacing install lib would be #6481
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.
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?
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.
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?
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.
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?
Apologies, I linked to here from an unrelated ticket due to off-by-one error. :)
I'm a linux person myself so am hazy on the details of other systems as well..
I'm surprised that it even installs the executable in the first place, given #7360
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
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.
well, the workaround is a "one-liner" too, only longer stuck_out_tongue_closed_eyes
Compatibility across windows and unix is tricky, though.
I am developing on windows and that one liner works in raw cmd. It also works on linux sh.
powershell would need replace &&
with ;
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:
System information
cabal 3.6.2.0
,ghc 9.2.3