proposal: Prohibit external packages about book-of-examples

[Anton-4]

I would use that instead of a community package that may be more mature and feature complete.

Yeah sounds good, the user will already be familiar with that API 👍

[jwoudenberg]

I was thinking of using roc-json in the CI chapter. I probably can use another serialization/deserialization format instead if a chapter gets written for one (given some constraints). I'm not entirely clear on the value though, and do see some downsides in terms of dependencies between chapters we'd introduce both for ourselves as we're writing and readers.

I do think we should avoid relying on libraries for solving the interesting parts of the problem each chapter is about. I think using a package for commodity functionality like JSON parsing or random number generation is fine though!

[jwoudenberg]

I want to add, in referring to JSON parsing or random number generation as commodity functionality I was thinking as a user of a library providing that functionality. I know a lot of work and thinking goes into building one!

[nathanielknight]

I would agree that we don't necessarily want the book to be hermetic, and we want to think about providing:

• a link to most up-to-date version of the library (for someone reading in a few years who needs a JSON decoder)
• a link to the version of the library used for the chapter (for a reader who wants the source code/documentation)
• a stable link to the files needed to run the code (so that code examples continue to work)

GitHub releases or signed tarballs on the book's website might work okay for the last point?

[Anton-4]

Github releases work well, we also have a github action that can take care of the whole release process.

[Anton-4]

I'm not entirely clear on the value though, and do see some downsides in terms of dependencies between chapters we'd introduce both for ourselves as we're writing and readers.
I do think we should avoid relying on libraries for solving the interesting parts of the problem each chapter is about. I think using a package for commodity functionality like JSON parsing or random number generation is fine though!

I agree with this.

[Anton-4]

External packages imported from an url are fragile, especially if those urls are out of our control.

I think all external packages we currently use were authored by people who collaborate on the book, so that seems acceptable to me.

[HajagosNorbert]

Alright, I can get behind these arguments. If a package built within a chapter is suitable for other chapters (like I assume the random package will be), I would use that instead of a community package that may be more mature and feature complete. In that case that package would need a Github release.

What is your opinion, would it be better to do it that way, or stick to a more realistic scenario, in which a more accepted package is used? (Thus eliminating the need of releasing the chapter packages)

[gvwilson]

Thank you all for the discussion - I'll flag this to be voted on for the 2024-04-10 meeting.