Closed ee7 closed 1 year ago
I looked at the repositories that have a fetch-configlet
file with a different filename.
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
.
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:
fetch-configlet
scripts, which happen in a different repo.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 https://github.com/exercism/configlet/issues/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:
org-wide-files
to sync files that live in a different repo.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.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
: https://github.com/exercism/configlet/issues/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 abash
script, not ansh
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.
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.
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:
How about having Configlet do it? Configlet is also only in the track repositories.
Could you elaborate? Do you mean:
exercism/configlet
, and update track repos manually without using org-wide-files
"?configlet
executable or the configlet
CI workflow update the fetch script in track repos"?Here's some more past discussion, in case it's useful:
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):
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.
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
:
Maybe it could.
It would make sense to target it. That way newly bootstrapped repositories would be fully up-to-date.
Yeah that makes sense. Could you create an issue?
Could you create an issue?
I would prefer the
fetch-configlet
scripts to live in theconfiglet
repository. But I would also preferorg-wide-files
to do the syncing, especially since it can supporttracks-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:
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 https://github.com/exercism/configlet/commit/0be1889317f22196a2a5cafa2f8f5179a84faa87).
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:
And of those, only 13 are active tracks:
It was added to request-new-language-track
in https://github.com/exercism/request-new-language-track/commit/7b144840cf838df361a928c9144fd9db3add672f.
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?
I'm fine with duplicating them.
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).
Well, I think it would make sense to have them sync too, but only for the tracks interested in them. We could maybe use the org-wide-files-config.toml
file that we also used to enable or disable format checking (see https://github.com/exercism/julia/blob/main/.github/org-wide-files-config.toml).
I believe the ps1 script is in all tracks at the moment (I made the incorrect assumption that this was the desired behavior, so I added them in the last batch sync PRs).
This script would be used by any contributor/maintainer who is developing on a Windows machine, right?
I believe the ps1 script is in all tracks at the moment
Incorrect, right? As far as I'm aware, what I wrote at the bottom of https://github.com/exercism/org-wide-files/issues/262#issuecomment-1304634330 is accurate. I think it's just tracks that were bootstrapped after 2020-10-09, plus a tiny few where maintainers added it manually (exactly cpp, csharp, dart, fsharp, javascript, typescript).
$ cd my-dir-with-every-exercism-track
$ find . -name 'fetch-configlet.ps1' | sort
./8th/bin/fetch-configlet.ps1
./abap/bin/fetch-configlet.ps1
./awk/bin/fetch-configlet.ps1
./bqn/bin/fetch-configlet.ps1
./chapel/bin/fetch-configlet.ps1
./cobol/bin/fetch-configlet.ps1
./cpp/bin/fetch-configlet.ps1
./csharp/bin/fetch-configlet.ps1
./dart/bin/fetch-configlet.ps1
./free-pascal/bin/fetch-configlet.ps1
./fsharp/bin/fetch-configlet.ps1
./gnucobol/bin/fetch-configlet.ps1
./javascript/bin/fetch-configlet.ps1
./jq/bin/fetch-configlet.ps1
./openeuphoria/bin/fetch-configlet.ps1
./qsharp/bin/fetch-configlet.ps1
./red/bin/fetch-configlet.ps1
./solidity/bin/fetch-configlet.ps1
./typescript/bin/fetch-configlet.ps1
./unison/bin/fetch-configlet.ps1
./vlang/bin/fetch-configlet.ps1
./wasm/bin/fetch-configlet.ps1
./wren/bin/fetch-configlet.ps1
./z3/bin/fetch-configlet.ps1
./zig/bin/fetch-configlet.ps1
Listing the Exercism track repos by creation date:
gh repo list exercism --limit 300 --topic exercism-track \
--visibility public --no-archived \
--json createdAt,name --jq 'sort_by(.createdAt)' \
| jq
This script would be used by any contributor/maintainer who is developing on a Windows machine, right?
Sort of. I guess it depends on whether they prefer PowerShell?
I think that a lot of developers on Windows use bash, and/or WSL. And I imagine that more people can read sh/bash than PowerShell, even developers on Windows.
But PowerShell is installed by default on every Windows OS from Windows 7 onwards, and bash isn't, so I do think there's value in providing the PowerShell script. It just takes more effort to maintain two scripts that do the same thing, and I don't know how many potential configlet users only have PowerShell installed.
But I left Windows a long time ago, so I'll defer to @ErikSchierboom here.
Also, about half of the fetch-configlet.ps1
scripts aren't up to date, and the csharp track has a unique one with non-upstreamed changes:
$ find . -name 'fetch-configlet.ps1' -exec md5sum {} + | sort
83fd8dfbde28fab5d05e54ceec9aca5a ./abap/bin/fetch-configlet.ps1
83fd8dfbde28fab5d05e54ceec9aca5a ./qsharp/bin/fetch-configlet.ps1
83fd8dfbde28fab5d05e54ceec9aca5a ./red/bin/fetch-configlet.ps1
83fd8dfbde28fab5d05e54ceec9aca5a ./wren/bin/fetch-configlet.ps1
83fd8dfbde28fab5d05e54ceec9aca5a ./z3/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./8th/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./awk/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./bqn/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./chapel/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./cobol/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./dart/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./free-pascal/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./gnucobol/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./jq/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./openeuphoria/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./unison/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./vlang/bin/fetch-configlet.ps1
88ebec802498c789810c9b7f6e74413e ./wasm/bin/fetch-configlet.ps1
9edfc3e55870eb9476ba178524d1ec84 ./cpp/bin/fetch-configlet.ps1
9edfc3e55870eb9476ba178524d1ec84 ./fsharp/bin/fetch-configlet.ps1
9edfc3e55870eb9476ba178524d1ec84 ./javascript/bin/fetch-configlet.ps1
9edfc3e55870eb9476ba178524d1ec84 ./solidity/bin/fetch-configlet.ps1
9edfc3e55870eb9476ba178524d1ec84 ./typescript/bin/fetch-configlet.ps1
9edfc3e55870eb9476ba178524d1ec84 ./zig/bin/fetch-configlet.ps1
c1fc9dc384a9969a398212a71a752e3c ./csharp/bin/fetch-configlet.ps1
I think that a lot of developers on Windows use bash, and/or WSL. And I imagine that more people can read sh/bash than PowerShell, even developers on Windows.
In my experience, this is not true. I've worked in a lot of Windows environments and PS was used for more than sh/bash.
But PowerShell is installed by default on every Windows OS from Windows 7 onwards, and bash isn't, so I do think there's value in providing the PowerShell script. It just takes more effort to maintain two scripts that do the same thing, and I don't know how many potential configlet users only have PowerShell installed.
There is, but it isn't that these scripts change that much, so I think there's value in keeping them.
Well, I think it would make sense to have them sync too, but only for the tracks interested in them. We could maybe use the org-wide-files-config.toml file that we also used to enable or disable format checking
so I think there's value in keeping them.
As long as I don't have to maintain it :)
So, let's add fetch-configlet.ps1
to org-wide-files
, but make it opt-in - by default only syncing to tracks that already have the file present? org-wide-files
can do that, right?
org-wide-files can do that, right?
Not yet no. And I don't know Julia: https://github.com/exercism/org-wide-files/blob/main/scripts/apply-track-config.jl 😱
Is there a mechanism for tracks to configure which (optional) files they want? If so I think it's fine to make the .ps1
file optional and only sync it if the track adds it to the configuration.
Is there a mechanism for tracks to configure which (optional) files they want? If so I think it's fine to make the .ps1 file optional and only sync it if the track adds it to the configuration.
There isn't, we'd have to build it ourselves.
I think my suggestion right now is to get the basic fetch-configlet
script included now, and leave the .ps1
script off. Let's just leave people to get ps1 updated if they care about it (for now).
Sounds like a plan
Closed by: https://github.com/exercism/org-wide-files/pull/267
Let's track the idea to add fetch-configlet.ps1
in a separate issue: #280
Follow-up from https://github.com/exercism/elixir/pull/1218#issuecomment-1285847533 and https://github.com/exercism/elixir/pull/1217#issuecomment-1285855493
Let's try to:
CODEOWNERS
specifies the correct filename in every track repo - some repos had different filenames forfetch-configlet
in the past.fetch-configlet
-updating process also target https://github.com/exercism/request-new-language-track/