List of supported crates should also include supported version(s)

[coriolinus]

When authoring an exercise which requires a dependency, we could reduce guesswork by including the list of supported versions in the supported_crates file. This means that an exercise author can simply specify the appropriate version directly from the file, instead of naming the most recent version and hoping.

[dhovart]

Feel free to assign this to me.

[dhovart]

@coriolinus I'll list dependencies in the format expected by Cargo.toml under [dependencies].

I was thinking of providing also a script to refresh one or all of them.
Something like:

./refresh-supported-crates-list --all
./refresh-supported-crates-list --dep chronos

Would that do ?
It would just retrieve the latest version(s) from crates.io

[coriolinus]

I'll list dependencies in the format expected by Cargo.toml

Sounds great to me!

I'm not sure what you mean by refreshing them, unless that's also regenerating the container. The idea is that whatever version is current on crates.io, we can use the version from the file in the online environment and things work.

[dhovart]

I'm not sure what you mean by refreshing them, unless that's also regenerating the container.

It's just that this file is used as the source of truth for generating the local registry we store the crates in. We were thinking of storing the file in the exercism/rust repo (see exercism/rust#1408)

If it's not regularly updated the registry will go stale and we'll be stuck with old crates versions.

As it requires some manual work to retrieve the newest version on crates.io and update the versions in this file, I was thinking of a script to help with this task.

Also, do you think it makes sense to support multiple crate versions ?

[coriolinus]

Ah, OK. I think that the same script which generates the image should update the versions in this file. My goal is to make it very unlikely that the file gets out of sync with the image. I think it's fine to support only the most recent version per crate.

…

On Thu, Dec 2, 2021, 16:10 Denis Hovart ***@***.***> wrote: I'm not sure what you mean by refreshing them, unless that's also regenerating the container. It's just that this file is used as the source of truth for generating the local registry we store the crates in. We were thinking of storing the file in the exercism/rust repo (see exercism/rust#1408 <exercism/rust#1408>) If it's not regularly updated the registry will go stale and we'll be stuck with old crates versions. As it requires some manual work to retrieve the newest version on crates.io and update the versions in this file, I was thinking of a script to help with this task. Also, do you think it makes sense to support multiple crate versions ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3V4TTM7PXHKPYSFXKJMKDUO6EAFANCNFSM5JFIOJVA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dhovart]

All right, then I'll close exercism/rust#1408 and we can keep the supported_crates file here.

In which way should the file containing the new versions be pushed to this repo after each build ? Something like a GH action ?

[coriolinus]

I believe that there is separate tooling which detects the existence of a new image and propagates it to the website. IMO life is simplest if that tool also opens a PR here to update the file. However, I'm not the domain expert in that process. Maybe @ErikSchierboom?

[ErikSchierboom]

We have a workflow that only runs when something is pushed to main: https://github.com/exercism/rust-test-runner/blob/main/.github/workflows/docker.yml

You could create another workflow that also only runs when something is pushed to main. That would be my preference, as the other workflow should be identical across tracks.

[dhovart]

I see an issue here. You want me to create a workflow that is run when something is pushed to main, at the same time the container is built. It would create a PR with the updated supported_crates file, if its content has changed.

But then as the PR will be merged and pushed to main this will trigger a new execution of the docker workflow.

Is there a way to prevent the docker workflow from being executed a second time ?
It doesn't seem easy without updating it and from what I understand you want to keep it the same for all test runners.

[dhovart]

I suggest a workflow to regenerate supported_crates and create a PR that is only run once per week. Would that do ?

[coriolinus]

Yes, I think that sounds reasonable. That way, the only human interaction required is to ensure that the list of supported crates / versions remains sane and merge. The other workflow will capture the merge and regenerate the docker image, keeping things synchronized.