I think renaming the slug might be the way to go here. Deprecation seems more appropriate if the exercise turned out to be a bad fit like for Pyret which generally uses linked lists. The problem here though is different because it’s just a namespace collision. For this exercise, I think it’s safe to break the connection to problem specs. The most recent test suite addition was eight years ago, and the instructions were last updated three years ago. That implies the exercise is fairly stable in its current form.
Another approach would be to add support to the configlet to support a rename map. That would also be useful for those three Haskell exercises that conflicts with package names.
1 Like
Can a mod split this thread and move the configlet stuff over to Building Exercism? This should be discussed more broadly than what might be possible in a track-specific feedback thread.
1 Like
Alright, Discourse destroyed some context here.
My original post here was originally a response to keiraville at Factor Track Feedback - #16 by keiraville. The thread title, on the other hand, refers to Isaac’s response to keiraville which is now the second post here. We forked the thread so this could be a more visible discussion for maintainers. This is currently an issue that affects at least two tracks, Haskell and Factor.
Personally, I don’t have a strong feeling for or against as long as some folks chime in. If we do add this feature, I would recommend any new optional track config keys be documented in the Exercism docs.
I understand the problem. I don’t completely understand, why setting specification for the problem-specification slug is chosen and not local-slug or similar for some local modification of the slug? Instead of generally changing the meaning of slug in the global configuration I’d prefer adding a variation when locally required.
2 Likes
Tomato, tomahto?
If the slug stays the same, tools that use the slug to identify the path need to be updated (including the website). If the slug changes, tools that use the slug to identify the problem spec need to be updated (including the configlet).
It’s a question if which of those mappings is worse to break and which tooling will need to be updated.
2 Likes
The PR has merged.
Ideally we will also release a new version of configlet so that the new functionality is available to
-
Maintainers using
bin/fetch-configlet(instead of buildingconfigletthemselves) -
Tracks having
with:fmt: truein configlet.yml
Currently using problem_specifications_slug passes CI, but if with: fmt: true is also used we have failure
1 Like
If anybody else is keen, that would be wonderful.
A couple of minor things for people to be aware of:
std/re
One of the tests uses re which does not work for me with a ubuntu-26.04 laptop.
This is both before and after the move to a more recent Nim release. Tests run successfully in a ubuntu-24.04 docker container.
From a LLM:
could not load: libpcre.so is a gap in your system, not in the code. tests/test_binary_create.nim uses Nim’s std/re, which needs the old PCRE1 library (libpcre.so.3). Your machine only has PCRE2, and apt doesn’t offer libpcre3 here, because recent Ubuntu releases dropped it. all_tests.nim builds every test into one binary, so the whole suite fails to start. … Rewriting those two calls with strutils (find and slicing) would remove the dependency.
Unsorted output
I delegated the RELEASE.md step “Ideally, check that configlet lint and configlet sync don’t produce unexpected output on any track - diffing the output from the previous release.” to a LLM
- lint differences: only common-lisp, crystal and zig differ, and in each the warning lines are identical but in a different order. These are the “Concept X appears N times in the practices arrays…” warnings. The code builds them by iterating a CountTable (src/lint/track_config.nim:346), so the order shifted with the Nim upgrade. It’s harmless, though sorting by concept name would make the output stable.
We could make the output stable by sorting (GitHub - keiravillekode/configlet at sort-overpracticed-concepts · GitHub) but I don’t think that is worthwhile. We could instead consider updating the 3 tracks so the warning no longer occurs.
Four more lint reports print in hash-set order, all in src/lint/track_config.nim. Like the one I just fixed, their order is stable for a given Nim version but can change when the compiler is upgraded, which is what happened between 4.0.2 and main.
Proc: checkExerciseSlugsAndForegone
Line: 626Proc: checkFilePatternsOverlap
Line: 672Proc: checkExerciseDirsAndTrackConfigAreInSync
Line: 740, 748Proc: checkConceptDirsAndTrackConfigAreInSync
Line: 785, 791
1 Like
https://github.com/exercism/configlet/pull/948
The build workflow uses Ubuntu 24 so the compat issue with Ubuntu 26 can be ignored until another release.
I ran a test build. It complained about Node 20 being deprecated and using Node 24 but otherwise the test build looks promising.
I was under the impression that it was already sorted. I would rather fix this within configlet and be done with the problem entirely. Fixing the affected tracks means deferred maintenance for configlet itself. Let’s just pop in and fix configlet ‘s sorting issue.
Agree with fixing this in configlet rather than touching the three tracks. Sorting the warning lines right before they are printed should make lint output deterministic without changing track configs, and it keeps the release diff meaningful. The Ubuntu 26 PCRE failure sounds separate from this release since the build workflow is on 24.04; I would not block the release on it. A small test with multiple warnings would help prevent the ordering from regressing later.
A change to sort these is merged
I didn’t merge any new tests that would capture test output - possible generated tests seem out of proportion to the change.