Support external dependencies in the Go track

[andrerfcsantos]

This issue is meant as a discussion and tracking issue for the support of external dependencies in the Go track.

Current state

Right now the test-runners run in a container with no network access, which makes the use of external dependencies not possible at the moment.

Possible solution

A possible solution is to have a list of allowed external dependencies in a file, and make the Dockerfile of the test runner fetch those dependencies when building the image. That way, if a student uses an external dependency in a solution, the test runner (and other tooling) can use the local copy it has pre-built in the image instead of trying to fetch it on the fly, hence requiring no network access.

The Rust track currently does this. Here's an example of the Rust test-runner Dockerfile:
https://github.com/exercism/rust-test-runner/blob/e343e83b35badd61391d86b17d2adbd42f534c3f/Dockerfile#L15-L19

List of allowed dependencies

The list of allowed dependencies is something that we still want feedback on. Some things that were discussed before as possibly good candidates:

• stretchr/testify - we could use it on our tests to simplify some logic, and students could use it too for some debugging possibly
• golang.org/x/* packages - extension packages, some contain useful things.
• Generic libraries - with the advent of generics,some useful libraries commonly used by the community might appear. An example of a library with such potential would be samber/lo.

[bobahop]

All of those sound good to me, but I don't know how much it may complicate things for the maintainers. I'm not sure I would even know how to prioritize them. They are "nice to have" but maybe not "must have."

[andrerfcsantos]

The more I look into it, I think it might simplify things for us actually. Specially the dependencies around tests, it means we can have more standard ways to write tests. An example of this is how on some tests we are repeating functions to check if slices are the same, or if two floating point numbers are the same given a threshold - I think it would be fine to delegate these tasks to an external dependency and have a standard way to do things.

And of course, if we can also make life easier for students without completely ruining an exercise that can be just solved with using a dependency, the better.

The add maintaining cost of course would be to keep the dependency list updated, but I see that as a worthwhile price to pay.

[junedev]

While both relate to adding packages in the test runner, I think there are two separate issues to consider here and I will note down my thoughts on those separately.

1. Do we want to use some external package as assertion library in all the exercise tests?
2. Do we want to bake-in additional packages into the test runner so that the students can use those when solving the exercises?

I created a separate issue for point 1: #2411
@andrerfcsantos Would be good if you could copy/add your thoughts there.

Re question 2: Instead of making up some selection, I would like to keep this on an on-demand basis for now. So the constraints package is the only "demand" I am aware of right now. @andrerfcsantos Is there anything else that was actually requested by students so far?

[andrerfcsantos]

From the top of my head, dependencies that would be good to add would be:

• golang.org/x/text/cases - mainly because it has cases.Title, which is the recommended function to use instead of the deprecated strings.Title function of the standard library. I don't know at the top of my head, but I remember a function like this being potentialy useful in some exercises.
• golang.org/x/text/number and golang.org/x/text/currency - some students try to use this in the Ledger exercise to format numbers and currencies according with different locales. It's not required to complete the exercise, as students can write their own functions to achieve similar goals without too much effort, but since it is a small part of the exercise as a whole, I don't mind students trying to explore these libraries that can help them.
• golang.org/x/exp/constraints - as mentioned before, to allow students to play with generics more easily.

[junedev]

@andrerfcsantos Do you know how/where other tracks document which dependencies are available so students could look it up if needed?

[andrerfcsantos]

The only place I know to look for these is the file with the dependencies used in the build of the docker image: rust's supported_crates file.

But I think we can include this list easily in the track docs.

One thing Rust had problems in the past and would be great if we could avoid, is also to be clear about the versions of the dependencies. That supported_crates file doesn't specify versions, which means rust will grab the latest available version of every crate at the time of building the image. This caused problems when a student on slack was trying to use a more recent version of the crate than the one exercism had. So it would be great if we could pin specific versions when building the docker images and also be clear about which version of each dependency we have.

[junedev]

If those two don't get added in 1.20, we should also consider adding them to our list:

• https://pkg.go.dev/golang.org/x/exp/maps
• https://pkg.go.dev/golang.org/x/exp/slices

I thought they would land with 1.19 but they didn't.