Consider reintroducing --prob-specs-dir

[senekor]

This flag can be found in the README, but it's not yet included in configlet --help.

[senekor]

Actually it seems the README is just outdated:

The --prob-specs-dir option was removed in configlet 4.0.0-beta.1 (April 2022).
A plain `configlet sync` now caches the cloned problem-specifications in your
user's cache directory - there is no longer an option to configure the location.
Performing an offline sync now requires only one option (--offline), but you
must first run a `configlet sync` command without --offline at least once on
your machine.

This is terrible news for me. I want to use a git submodule to pin a specific revision of problem-specifications on the Rust track.

Could it be considered to add this option back?

[ee7]

From the configlet 4.0.0-beta.1 release notes:

Despite the --prob-specs-dir removal, note that you can still:

• Sync from an older prob-specs commit, by checking out that commit in the cached repo and then using --offline. This can be helpful when, for example, creating atomic commits. We require the commit to exist on the upstream main branch.

Does that help at all?

Actually it seems the README is just outdated

Indeed.

[senekor]

I guess this is doable, but it has a couple downsides. I need to write a wrapper around configlet to handle cloning and checking out at the pinned version. The local cache is different depending on platform. If it's just me, no problem. I'm using Linux and so is CI. But that would be a mean prank on potential contributors on other platforms. So that wrapper needs to be platform-independent... :( In summary, it's a lot of work.

[ee7]

I'm sympathetic towards wanting to pin the problem-specifications version. Is your main goal to run configlet sync in CI, and require it to exit with an exit code of 0?

If so: I want the configlet workflow to eventually support running configlet sync (probably as an opt-in; currently it's just lint, with an opt-in for fmt). We could support specifying a prob-specs commit to sync against, defaulting to the latest version. That's not as flexible as --prob-specs-dir, but is that good enough?

[senekor]

Yes, that is exactly my use case. It would be enough for me.

[senekor]

Using a git submodule still has some benefits:

• Track tooling can operate on files in problem-specifications without platform-dependent code to read from the configlet cache (e.g. test generators).
• The content is right there for easy reference :shrug:

But the two approaches can be combined: The commit hash passed to configlet can just be read from the state of the submodule. So this approach actually has no downsides for me.

And I need to apologize for opening a bad issue. I stated how I think my problem should be fixed, not what it actually is. Thank you @ee7 for asking the right questions and finding a better solution for my problem :smiley:

[ee7]

And I need to apologize for opening a bad issue. I stated how I think my problem should be fixed, not what it actually is. Thank you @ee7 for asking the right questions and finding a better solution for my problem 😃

No worries - it's a completely reasonable to think about --prob-specs-dir. Thanks for caring about pinning prob-specs. And sorry for:

• The bad configlet docs. They shouldn't mention --prob-specs-dir, and should've mention that you can git checkout in the prob-specs cache dir. I'll fix that.
• Not getting configlet sync into the Exercism-wide configlet workflow a long time ago.

---

New idea: configlet could gain a --prob-specs-commit <sha> option. The user (and the configlet workflow) can then use that option to specify a prob-specs state, rather than running git checkout in the prob-specs cache dir.

Would that help? The submodule approach still has the same advantages.

Other possibilities to help track-specific tooling, without adding --prob-specs-dir: configlet could gain a command to output the prob-specs cache dir location.

Getting the cache dir path is indeed a bit annoying, but it's not too bad:

The path to the cached prob-specs is:

$PATHSTART/exercism/configlet/problem-specifications

where the value of $PATHSTART is given by this table:

Platform	$PATHSTART
Windows	getEnv("LOCALAPPDATA")
macOS	getEnv("XDG_CACHE_HOME", getEnv("HOME") / "Library/Caches")
Other	getEnv("XDG_CACHE_HOME", getEnv("HOME") / ".cache")

and getEnv returns the value of the environment variable with the name of the first parameter (or if that does not exist, the value of the second parameter).

For example, on Linux, the cached path is typically:

~/.cache/exercism/configlet/problem-specifications

[senekor]

New idea: configlet could gain a --prob-specs-commit <sha> option.

That would be perfect for my use case.

Both other options work as well. I guess I overestimated the effort there. Reading a couple environment variables, cd'ing into the cache, checking out a commit, using configlet with the --offline flag. Not too bad at all.

I'm fine with closing this issue, given that implementing this quality-of-life feature in configlet may be much more work than just writing a couple lines of Bash myself.

[senekor]

After finally getting around to implementing this, I think it would still be nice to have that flag --prob-specs-commit <sha>. The bash scripts aren't insanely complicated, but it's just a very unfortunate heap of "white noise" in the repo.

https://github.com/exercism/rust/pull/1950/files