Skip to content

Make lukko flag default to off. #322

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

a-02
Copy link

@a-02 a-02 commented Jan 18, 2025

Based on discussions from haskell/cabal#10724, which was spurred by the comment here: haskellari/lukko#39 (comment)

@a-02 a-02 force-pushed the 10724-flip-lukko-flag-default branch from 3c6a5d3 to c7c0c2f Compare January 18, 2025 06:20
@Mikolaj
Copy link
Member

Mikolaj commented Jan 18, 2025

I was thinking we could start by flipping the flag in cabal, as the main user of hackage-security. However, this PR is a sensible second step. Or am I missing something?

@andreasabel
Copy link
Member

Note that so far we have a commented-out line turning off lukko in the project file:

-- constraints: hackage-security -lukko

This PR should also touch this line. Probably it makes sense to just delete it.

@a-02
Copy link
Author

a-02 commented Jan 18, 2025

I think I just misunderstood the ask from the dev meeting on Thursday. I can make the PR to set the lukko flag to off in cabal and get that done first before this.

@Bodigrim
Copy link
Contributor

I was thinking we could start by flipping the flag in cabal, as the main user of hackage-security.

You can flip it in cabal.project of Cabal, but it would not meaningfully help anyone who relies on Hackage source distribution. E. g., Stackage will still be in trouble if lukko is not updated in time.

However, this PR is a sensible second step.

One possibility is to keep default: True but set manual: False. In which case the solver will keep using lukko if available in current configuration but will flip the flag automatically and switch to base otherwise.

@Mikolaj
Copy link
Member

Mikolaj commented Jan 18, 2025

Thanks, Bodigrim!

Co-authored-by: ˌbodʲɪˈɡrʲim <[email protected]>
@Bodigrim
Copy link
Contributor

@Mikolaj @andreasabel what's the status of this? Could we please get it merged?

@Mikolaj
Copy link
Member

Mikolaj commented Apr 14, 2025

I'm sorry I've read the comment chain one time too many and now I'm confused. Weren't we supposed to change the flag first in cabal (I don't think we did; did we?) and only then, after some time, in hackage-security? See haskell/cabal#10724 (comment), unless we've developed a better deprecation plan since then. Did we?

@Bodigrim
Copy link
Contributor

You do you, but I think all this "developing a deprecation plan" is greatly overcomplicated. What's wrong with simply switching the flag in hackage-security? If you want to be super duper extra safe, both switch the default value and mark the flag as automatic, so that it can be switched back via a Hackage revision.

@Mikolaj
Copy link
Member

Mikolaj commented Apr 15, 2025

It's all about incentives. If anybody is keen enough to see this change through quickly and would like to take responsibility for the change process, patching and reverting as needed, I'm more than happy to assist in enacting the fast plan and then cleaning up the fallout.

By default, the cabal/hackage-security team is conservative, though.

@Bodigrim
Copy link
Contributor

Count me keen enough then :)

@a-02 could you please make the flag both automatic manual: False and disabled default: False? Making it automatic would allow me to switch it back by revision, if anything unforeseen happens.

@Mikolaj
Copy link
Member

Mikolaj commented Apr 17, 2025

Great! Let's do it!

@a-02
Copy link
Author

a-02 commented Apr 17, 2025

You got it, now its set to False in both fields.

@Mikolaj
Copy link
Member

Mikolaj commented Apr 17, 2025

Could you also please rebase? Maybe then Ci failures would vanish...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants