Open Amzd opened 2 months ago
Hey, yeah I think this is a cool idea. Before we decide on an implementation path, I'd like to know a bit more about how custom toolchains are typically installed though. Are they usually built from source? Or are they usually downloaded as tarballs, similar to regular releases or snapshots? If it's the latter, then I think this would best be supported by introducing a --custom-url
(or something like that) option to the install
command, rather than changing list
. If the former, then maybe a --toolchain-path
option could be introduced to install instead, which would allow one to specify a path on disk to use.
As a temporary workaround for your usecase, you can copy the toolchain to toolchains
directory and then add it to config.json
with some name you'll recognize that will also pass the parser (maybe some clearly nonexistent version such as 12.34.56).
My specific use case is step 1 of this https://github.com/kabiroberai/linux-app which requires a fork of spm which you just build locally. But unlike the steps I don't want to put it in my main 5.9.0 swift tool chain but in a copy (5.9.0-kabir) as otherwise it causes some other issues.
Would be nice to have some support for custom swift toolchains. This is helpful for development forks.
I tried just placing
5.10.0-example
in.local/share/swiftly/toolchains
but it was not picked up byswiftly list
.I don't mind making a PR if someone with more insight in the project has an idea on how to do this. Currently the installed versions is tracked in the config. Possibly could check the folders when you call
swiftly list
and add folders missing from config toconfig.installedToolchains
as a new ToolchainVersion case? egToolchainVersion.custom(String)
where String would be the folder name? I am probably not seeing all the possible issues with this approach.