Skip to content
This repository has been archived by the owner on Jan 5, 2024. It is now read-only.

Remove cabal update from setup upon request #29

Closed
newhoggy opened this issue Jan 27, 2021 · 12 comments · Fixed by #146
Closed

Remove cabal update from setup upon request #29

newhoggy opened this issue Jan 27, 2021 · 12 comments · Fixed by #146
Assignees
Milestone

Comments

@newhoggy
Copy link
Contributor

newhoggy commented Jan 27, 2021

I feel like cabal update should not be part of the setup. This is because cabal update will do project specific work and sometimes fail because of problems specific to the project.

For example:

image

Aside from this, the project may want to do cabal update after configuring the project, which duplicates work.

@newhoggy
Copy link
Contributor Author

newhoggy commented Jan 27, 2021

Aside from this, I've see the fatal: repository ... not found error multiple times today in more than one project. Has anyone else experienced this? Is this a Github infrastructure issue?

@hamishmack
Copy link

Would it make sense to change it to cabal update hackage.haskell.org (instead of removing it)?

@newhoggy
Copy link
Contributor Author

Possibly. Does that avoid cloning all the repositories?

@hamishmack
Copy link

I thought it would, but a quick test shows it does not. :-(

@hamishmack
Copy link

This works cabal update --project-file=$(mktemp)

@hamishmack
Copy link

But perhaps not on windows

@hazelweakly
Copy link
Collaborator

I've gotta say, I truly appreciate your ability to run headfirst into every corner case known to man. It's quite the talent :)

Running cabal update has been left in thus far because it was something that was done in the action originally and I didn't want to make a breaking change without bumping the major version.

Now that I can commit to the repository and have better control over versioning, removing cabal update from the action makes sense; I haven't actually seen any workflows that don't run cabal update on their own, anyway.


That all said.

This is because cabal update will do project specific work and sometimes fail because of problems specific to the project.

ughhhhhhhh (╯°□°)╯︵ ┻━┻

@liskin
Copy link

liskin commented Mar 27, 2021

I'd also appreciate the ability to disable cabal update. Not just cabal update actually, I'd love to be able to disable cabal installation entirely, without also disabling ghc installation.

Why I want this: when I let stack install ghc and then cache ~/.stack, the entire ghc installation (couple hundred MB) is cached for each job. With a somewhat elaborate build matrix, we're getting fairly close to the 5GB github actions cache limit. Therefore I'd like to let stack use the system ghc, but haskell/actions/setup insists on also installing cabal and performing cabal update, which takes an additional 30+ seconds and wastes bandwidth.

@liskin
Copy link

liskin commented Mar 28, 2021

Oh, turns out I can just do:

sudo apt install -y ghc-${{ matrix.ghc }}
echo /opt/ghc/${{ matrix.ghc }}/bin >> $GITHUB_PATH

(full context: xmonad/X11@ebaff90)

Wouldn't be as simple if I wanted this to work on Windows and MacOS as well, but those aren't relevant for xmonad, so I'm fine for the time being. :-)

liskin added a commit to liskin/X11 that referenced this issue May 14, 2021
Since actions/runner-images#3268, the GHC PPA is no longer
enabled by default. :-(

(It would be better to use the haskell/actions/setup action, but it
insists on doing `cabal update` even if all we need is to install GHC
and Stack, which adds noticeable delay:
haskell/actions#29)
liskin added a commit to xmonad/X11 that referenced this issue May 14, 2021
Since actions/runner-images#3268, the GHC PPA is no longer
enabled by default. :-(

(It would be better to use the haskell/actions/setup action, but it
insists on doing `cabal update` even if all we need is to install GHC
and Stack, which adds noticeable delay:
haskell/actions#29)
liskin added a commit to xmonad/xmonad that referenced this issue May 14, 2021
Since actions/runner-images#3268, the GHC PPA is no longer
enabled by default. :-(

(It would be better to use the haskell/actions/setup action, but it
insists on doing `cabal update` even if all we need is to install GHC
and Stack, which adds noticeable delay:
haskell/actions#29)
@andreasabel
Copy link
Member

andreasabel commented Dec 28, 2022

@liskin: I think stack-no-global: true does exactly what you want (only install stack, not ghc nor cabal).

@hazelweakly wrote:

didn't want to make a breaking change without bumping the major version.

That would mean this cannot appear before v3.0.0?

Fixing the OP is a simple as removing one line:

if (!opts.stack.enable) await exec('cabal update');

PR:

@liskin
Copy link

liskin commented Dec 28, 2022

@liskin: I think stack-no-global: true does exactly what you want (only install stack, not ghc nor cabal).

Well there's a reason I typeset the "without also disabling ghc installation" part in bold…
Doing "exactly what I want" would have been making sure the desired versions of both slack and ghc are installed, but skipping cabal and cabal update. I don't think stack-no-global: true does that.

Anyway, all this stopped being relevant (for me) with the hvr-ghc PPA no longer being maintained. Having the haskell GH action install ghc via ghcup is no faster than having stack install it, so I can just use the GHA-provided stack and ignore this action entirely.

@andreasabel
Copy link
Member

andreasabel commented Jan 3, 2023

@newhoggy wrote:

I feel like cabal update should not be part of the setup. This is because cabal update will do project specific work and sometimes fail because of problems specific to the project.

In simple CI, you'd want cabal update to have run. Maybe we could have a new input cabal-update: false to turn off cabal update.

@andreasabel andreasabel changed the title Remove cabal update from setup Remove cabal update from setup upon request Jan 3, 2023
@andreasabel andreasabel modified the milestones: 3.0.0, 2.3 Jan 10, 2023
9999years pushed a commit to 9999years/haskell-actions that referenced this issue Mar 27, 2024
haskell#146)

This commit introduces a new boolean input `cabal-update` that defaults to `true`.  
If set to `false`, the `cabal update` step will be skipped.

The new flag `cabal-update` is proper boolean, it only accepts the YAML 1.2 truth values `true` and `false` (also in captial and uppercase).
This is contrast to other "boolean" flags that are "unset" by default and can be "set" with any non-empty string.

To test that `cabal update` happens, this commit also introduces a new Haskell test project into CI that depends on a common Hackage package (`base-orphans`).

Original commits:
* Fix haskell#29: new input 'cabal-update: false' to turn off 'cabal update'
* Test 'cabal-update: false'
* README: Add 'cabal-update' to table of inputs
* Accept YAML 1.2 booleans as values for 'cabal-update'
* CI: test 'cabal-update: true': project with Hackage dependency
* Default value for 'cabal-update'
* CI: use cabal_update (underscore) in matrix
* Fixup: project with Hackage dependency
* Work around haskell#158
* Extra clarification of boolean vs "boolean" inputs
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants