consider adding `fetch-configlet`

[ee7]

Follow-up from exercism/elixir#1218 (comment) and exercism/elixir#1217 (comment)

Let's try to:

• Ensure that CODEOWNERS specifies the correct filename in every track repo - some repos had different filenames for fetch-configlet in the past.
• Ideally, make the fetch-configlet-updating process also target https://github.com/exercism/request-new-language-track/

[kytrinyx]

I looked at the repositories that have a fetch-configlet file with a different filename.

• Rust: there are two files; the default, and a second one written in Rust. There was an issue requesting that the second one be added, but there was no context as to why.
• Fortran: there are two files; the default, and the second one written in Python. It looks like the second one was committed by accident, and I've asked the author to confirm.
• Elixir: there is only one file, with an alternate name. The PR that added the file was submitted before they realized that there was an upstream with a slightly different name.

The Elixir folks have confirmed that they're happy to switch to whatever is the org-wide standard, and mentioned a slight preference for having an explicit file extension (.sh).

I'm pretty sure that I'm the one who chose the original filename (hyphenated, no extension). This choice was made lightly, with little thought to alternatives. I simply used what was habitual for me.

The upstream repository has both a fetch-configlet script and a fetch-configlet.ps1 script. I think both should be added to the org-wide-files, and in order to be explicit, I think it would make sense to name the first one fetch-configlet.sh.

[ee7]

Now that I think about it again, moving the fetch-configlet scripts to the org-wide-files is a bit annoying for configlet developers because:

• a commit that alters the release assets in the configlet repo can no longer be atomic - it can't include the necessary change to the fetch-configlet scripts, which happen in a different repo.
• tests and CI (e.g. shellcheck) for the fetch-configlet scripts would also need to move to the org-wide-files repo. (Granted, the fetch-configlet script is not actually tested yet in CI, but it's tracked in fetch-configlet: add test configlet#121). This is only painful if we want to run the full tests of the configlet executable after downloading it with fetch-configlet, but I don't think that's very useful.

Without thinking too hard, maybe my preferences are:

1. Keep configlet as the upstream repo for the scripts, and allow org-wide-files to sync files that live in a different repo.
2. Make org-wide-files the upstream repo for the scripts, and remove the scripts from the configlet repo. Deal with not being able to see changes to the scripts in the same repo, and needing to commit to a separate repo to reflect certain changes in the configlet repo.
3. Same as 2, but keep the scripts in the configlet repo as a downstream (make org-wide-files target the configlet repo).

The fetch-configlet scripts are clearly files that we want in many repos, with a single source of truth. So it does make sense for them to live in the repo called "org-wide-files". If option 1 is too hard or strange then I'm OK with option 2. Option 3 might be a little confusing. Thoughts? Can we see any other options?

And in the time since we created org-wide-files, did GitHub add new mechanisms for synchronizing changes across multiple repos?

Edit: some not-especially-useful discussion from before we'd set up org-wide-files: exercism/configlet#310

---

I'm pretty sure that I'm the one who chose the original filename (hyphenated, no extension). This choice was made lightly, with little thought to alternatives.

I don't care that much about the file extension, but to give one point of view, the Google Shell Style Guide says:

Executables should have no extension (strongly preferred) or a .sh extension. Libraries must have a .sh extension and should not be executable.

It is not necessary to know what language a program is written in when executing it and shell doesn’t require an extension so we prefer not to use one for executables.

However, for libraries it’s important to know what language it is and sometimes there’s a need to have similar libraries in different languages. This allows library files with identical purposes but different languages to be identically named except for the language-specific suffix.

And from https://mywiki.wooledge.org/FullBashGuide:

please refrain from giving scripts a .sh extension. It serves no purpose, and it's completely misleading (since it's going to be a bash script, not an sh script).

And the fetch-configlet script is indeed a bash script, not a POSIX sh script.

However, from koalaman/shellcheck/issues#1369 (comment) bash shebang with .sh file extension seems common.

[kytrinyx]

That's good to know for the extension. I think it makes sense to leave it off, in that case.

The fetch-configlet scripts are clearly files that we want in many repos, with a single source of truth.

It just occurred to me that we don't actually want them in all the repositories. Just the track repositories.

How about having Configlet do it? Configlet is also only in the track repositories.

[ee7]

It just occurred to me that we don't actually want them in all the repositories. Just the track repositories.

The org-wide-files repo does have a concept of global files, tooling-specific files, and track-specific files:

• global-files
• tooling-files
• tracks-files

How about having Configlet do it? Configlet is also only in the track repositories.

Could you elaborate? Do you mean:

• Keep the status quo: "keep the scripts in exercism/configlet, and update track repos manually without using org-wide-files"?
• Keep the status quo, but add a script/workflow to the configlet repo that opens PRs to update scripts in track repos?
• Something like "make the configlet executable or the configlet CI workflow update the fetch script in track repos"?
• Something else?

[ee7]

Here's some more past discussion, in case it's useful:

• Centralize fetch / install script v2-configlet#181

We did decide against "make the fetch-configlet script in track repos download and execute the latest fetch script" at one point (and I'd still be against that option):

• Fetch script now downloads script to execute configlet#139 (comment)

[kytrinyx]

I would prefer the fetch-configlet scripts to live in the configlet repository.
But I would also prefer org-wide-files to do the syncing, especially since it can support tracks-files.

I think my preference would be to see if we can make org-wide-files get the file from the configlet repository without that turning into a mess.

[ee7]

Great. Sounds like we're on the same page here.

I've reminded myself that org-wide-files does not currently target exercism/request-new-language-track in PRs for tracks-files:

• Update org-wide-files generic-track#127

Maybe it could.

[kytrinyx]

It would make sense to target it. That way newly bootstrapped repositories would be fully up-to-date.

[ErikSchierboom]

Yeah that makes sense. Could you create an issue?

[ee7]

Could you create an issue?

Done: #263

[ee7]

I would prefer the fetch-configlet scripts to live in the configlet repository. But I would also prefer org-wide-files to do the syncing, especially since it can support tracks-files.

I think my preference would be to see if we can make org-wide-files get the file from the configlet repository without that turning into a mess.

@kytrinyx and @ErikSchierboom - any idea how easy this is?

There's a bunch of fetch-configlet script changes in the pipeline:

• exercism/configlet@5f5b54d
• exercism/configlet@013c66b
• .github, fetch-configlet: rename release assets configlet#705

so it could be nice to get org-wide-files to handle the mass PRs.

If it's not easy, what do we think about just duplicating the scripts for now? That is: keep fetch-configlet scripts in the configlet repo, add them to org-wide-files too, and update them in org-wide-files when we want to distribute the changes?

Note that in the time since my posts above I've added testing of both bash and PowerShell fetch-configlet scripts to CI in the configlet repo (see exercism/configlet@0be1889).

Also, should we add the PowerShell script to org-wide-files? I lean towards "no", but we do need to update it on every track that it exists (for the same upcoming asset renaming). I'm not a PowerShell user, so I don't want to commit to maintaining it, and it will need more updates in the future (see open issues for fetch-configlet).

At the time of writing, the fetch-configlet.ps1 script exists in these 25 (of the 92) track repos:

• 8th
• abap
• awk
• bqn
• chapel
• cobol
• cpp
• csharp
• dart
• free-pascal
• fsharp
• gnucobol
• javascript
• jq
• openeuphoria
• qsharp
• red
• solidity
• typescript
• unison
• vlang
• wasm
• wren
• z3
• zig

And of those, only 13 are active tracks:

• abap
• awk
• cobol
• cpp
• csharp
• dart
• fsharp
• javascript
• red
• typescript
• unison
• wasm
• wren

It was added to request-new-language-track in exercism/generic-track@7b14484.