replace memory with ram

[jappeace]

attempt to get rid of basement
we can't modify memory but I can replace it with a copy which no longer uses basement.

for context: https://discourse.haskell.org/t/fork-basement-as-baseplate/12415/72
cf: kazu-yamamoto/crypton#67

my little worker bee asserted the tests pass and it builds: jappeace#1

[kazu-yamamoto]

Cc: me

[Yuras]

I'm not a maintainer, so the following is just a personal opinion.
If I understand correctly, now htttp-client-tls will build with tls-2.3.0, but not with tls-2.2.2. Is it correct?
Is there way to avoid it, e.g. put memory vs ram behind a flag? If not, then IMO tls version bound needs to be updated.

[jappeace]

@Yuras the idea is that we swap all of these libraries over in one go.
use tight upper bounds if you don't want to switch yet.

NB: I wanted to get memory maintainership preferably, but that doesn't seem possible right now, so this is the next best thing.

[Yuras]

the idea is that we swap all of these libraries over in one go.

@jappeace OK, but then it makes sense to update tls upper lower bound, doesn't it? Right now it's tls >= 2.1.2, why would you keep it if you know http-client-tls won't build with tls earlier than 2.3.0?

this is the next best thing.

Probably I'm misunderstanding what's going on here, but won't it be better if http-client-tls would support both? That way we'll avoid ripple effect throughout the ecosystem. Assuming it's possible to support both of course. Am I missing something?

[jappeace]

but then it makes sense to update tls upper bound, doesn't it?

yes it will allow cabal to make better plans. by default it'll pick "as high as possible".
one issue is that previous versions would've needed upper bounds for this to be opt in as well.

Someone would have to go trough all these http-client-tls hackage releases and add upperbounds to tls for example.

(I think hackage maintainers allow bound changes for this exact reason).

Probably I'm misunderstanding what's going on here, but won't it be better if http-client-tls would support both?

it's not trivial to do. ram exposes the same api as memory (it's a little different because we rely on base and ghc-prim instead of basement),
however you'll get type errors if you mix types from ram and memory even though they have the same name.
It'd be confusing!

For this reason by default cabal doesn't allow you to install multiple versions of the same library. But this rename has caused this situation to occur anyway. 😔

if you're interested there is a discussion on all this: https://discourse.haskell.org/t/fork-basement-as-baseplate/12415/77

[Yuras]

I have an impression we are talking past each other. I guess a typo in my previous comment contributed to the confusion, sorry for that.
I'm not suggesting to update previous releases, just to change tls >= 2.1.2 here to tls >= 2.3.0 to reflect the reality.

it's not trivial to do.

OK, if you say so. Though I don't see why it won't work. Just to make sure we are talking about the same thing, by "hiding it behind a flag" I meant adding cabal flag in http-client-tls.caba, something like this:

flag memory
  default: false
  manual: true -- or even false to let cabal decide?
-- <..>
library
  if flag(memory)
    build-depends: memory
  else
    build-depends: ram

That way someone can e.g. temporary set http-client-tls +memory in their cabal.project.lock file while waiting for the ecosystem to catch up.

if you're interested there is a discussion on all this: https://discourse.haskell.org/t/fork-basement-as-baseplate/12415/77

I didn't find any discussion of how to avoid ripple effect there. Though the thread is quite long, I could've missed it.

ADDED:
Probably even this:

flag memory
  default: false
  manual: false
-- <..>
library
  if flag(memory)
    build-depends: memory,   tls < 2.3.0
  else
    build-depends: ram,   tls >= 2.3.0

[sol]

@Yuras @jappeace I did not read the whole discussion, nor do I intend to, but:

1. We don't want to support ram and memory at the same time (even if it were possible, it's just a waste of time and effort)
2. Somebody has to add Hackage upper bounds to affected package, to rule out broken install plans. Right now, many things are just broken, which IMHO is not acceptable.

[jappeace]

We've a tight bound on tls now for the next release in this PR.

it doesn't solve the issue where previous versions don't have upper bounds and I don't have permissions to change that either.

[kazu-yamamoto]

My intention is:

• If one package selects tls v2.2, memory is used.
• If it chooses tls v2.3, ram is used.

The boundaries in tls.cabal of v2.2.2 was loose and I have just updated it on Hackage.
I hope this update implements my intention correctly.
If not, I should dig the source of this problem deeply.

[kazu-yamamoto]

@Yuras Do you still see the problem?

[Yuras]

@Yuras Do you still see the problem?

@kazu-yamamoto Sorry, I'm not sure which problem you are referring too. If it's about the lower bound on tls in http-client-tls, then @jappeace already corrected it, so I don't see anything wrong with the PR.
If you are asking about the cabal flag to support both older and newer versions of tls, then it was just a suggestion, there were no problem to begin with. And @sol clearly doesn't want it anyway.

[kazu-yamamoto]

@Yuras I guess I misunderstood and thought the problem was still there. Thank you for the clarification.

@snoyberg Could you merge this PR and release a new version?

[snoyberg]

I'm not going to be able to do any uploads myself for a bit. I'll be happy to add you as a maintainer on Hackage, but for some reason I'm not able to load any pages on Hackage at the moment. I'll try again later. In the meanwhile, I've invited you as a maintainer on this repo as well.

[snoyberg]

@kazu-yamamoto I've made you a maintainer on Hackage for all four packages in the repo.

[kazu-yamamoto]

@snoyberg Thanks!

Hackage is unstable recently: haskell/hackage-server#1467

May I ask to give me the Write permission of this repository to merge this PR?
Optionally, if it is hard for you to maintain these libraries, you might consider transferring this repository to yesodweb with new maintainers.

[Yuras]

May I ask to give me the Write permission of this repository to merge this PR?

@kazu-yamamoto Just to make sure you didn't miss it: the CI is failing because warp-tls is still using old tls: https://github.com/yesodweb/wai/blob/master/warp-tls/warp-tls.cabal#L25 I thought you are aware of it since you seems to be the maintainer of warp-tls, sorry if my assumption was wrong. (Was it the problem you were referring above? I might have misunderstood you.)
IIRC warp-tls is used in tests, so in theory we can merge the PR without waiting for warp-tls to be fixed, but IMO it's a bad idea.

Also I think technically I have right to merge into this repository, though I'd prefer to avoid doing this without maintainer's approval.

[kazu-yamamoto]

@Yuras I did not notice this. I think that relaxing the boundary of tls in warp-tls on Hackage is good enough.
I will do it.
But because Hackage is unstable, it would take time.

[kazu-yamamoto]

I should do the same thing for warp-quic.

[kazu-yamamoto]

@Yuras I think that this problem has been fixed.

[Yuras]

@kazu-yamamoto Indeed the code compiles now, but we have another problem. Tests are failing with the following error:

GHC.Internal.Event.Thread.getSystemTimerManager: the TimerManager requires linking against the threaded runtime

I managed to pin the issue down to warp. Specifically, tests pass with cabal test -c 'warp==3.4.9' all but fail with cabal test -c 'warp==3.4.10' all
I don't see anything in the changelog for warp-3.4.10 except a general note about dependencies. But in the repository I see a number of changes related to time manages. In particular this seems to be relevant: yesodweb/wai@32719ae

As a maintainer of warp, could you please clarify what might've caused the issue. Does warp not support non-threaded runtime anymore? I confirmed that, at least locally, enabling -threaded makes tests pass again.

[kazu-yamamoto]

time-manager v0.3 or later require threaded RTS.
You should use time-manager < 0.3.

[snoyberg]

@kazu-yamamoto it's just waiting on you accepting the invite

[kazu-yamamoto]

Oh. I just found your invitation! Thanks.

[kazu-yamamoto]

I think #572 is better than this PR.
So, I'm now working for #572.

[jappeace]

yes that's better, thanks

[kazu-yamamoto]

Closing.