This is incompatible with the changes of Gleam 1.7.0 (with all those deprecations and removals)

[oderwat]

Hi! Thanks for creating this package - it worked great in my initial testing.

I noticed it needs some manual patching to work with the current Gleam release. Are you still maintaining this project?

[inoas]

iterator.to_list has been moved to https://hex.pm/packages/gleam_yielder

[inoas]

https://hex.pm/packages/cake_gmysql cannot be upgraded to work with latest stdlib until gmysql has been updated.

Edit: inoas/gleam-cake-gmysql#1

[oderwat]

@inoas if nothing happens here, could you fork that and add it from your side? I do not yet have enough experience with Gleam and only evaluate things.

This makes me worry and I hope all is well with the maintainer:

[inoas]

@inoas if nothing happens here, could you fork that and add it from your side? I do not yet have enough experience with Gleam and only evaluate things.

This makes me worry and I hope all is well with the maintainer:

@oderwat cut @violetbuse some time.

Till then you can start a new project and remove the gleam stdlib version constraint, add gmysql and/or cake_gmysql first and it will work on an older version of the stdlib just fine. The recent versions of the stdlib mostly removed stuff / moved stuff to other packages, except dynamic/decode which you can use this for while waiting for gmysql to be updated https://hexdocs.pm/decode/1.1.0/

[oderwat]

@ionas I could but that is not how I develop. I don't like to keep thinks locked in the past. For know I just patched the gmysql package (and I think the array package?) inside of my project. I made no use of gleam-cake yet. The "good" thing is that I only needed mysql for migration as our newer projects are using PostgreSQL (or SQlite3).

[inoas]

Just push your local patches as a PR and see what happens?
Can be reused later on a fork if thats necessary.

[oderwat]

I am very new to Gleam and don't know much about the ecosystem and how it deals with cases of unmaintained packages. I also do not know to have my local project import a forked version (at some commit) in a proper way. I am Go developer and would add a "go.work" file or even have a replace in the "go.mod" file to deal with that. So far I think that Gleam tooling is like the "old" Go 'versioning' by vendoring the modules into the project repository and changing things like I did then get part of a commit or having a patch to apply after getting dependencies.

[inoas]

@oderwat feel free to join the community discord and tag me there and I will help you to help yourself, that way we all can help each other.