Installer will need to be updated in accordance with Nextercism CLI

[rpottsoh]

The CLI will be changing to be compatible with Nextercism. As the CLI is updated the Windows Installer will also need to be updated in order to remain compatible with the CLI. Namely, the Windows Installer invokes the configure command of the CLI. As the configure is updated changes may need to be made to the Installer. Environment variables may also need to be created as well..

See exercism/cli#410 to follow the progress of the CLI development for Nextercism.

[rpottsoh]

@kytrinyx will Windows releases of the CLI, going forward, be released in the same ZIP filenames that they are presently? My concern is that anyone still using the old Windows Installer will have issues during the install process when the installer tries to invoke configure --api= and --dir= commands. The new installer for Nextercism CLI will not be a problem.

The more I think about this, the latest release of the installer I think will be OK, but will end up displaying any error messages the CLI may display when the installer invokes the CLI with the old commands, but the install will otherwise be successful. I do not know how the older C# version of the installer will deal with the new CLI.

🤔 . this has kinda turned into a brainstorming session.... It might be a good idea if the Installer checked to see that IT is the latest release before downloading the CLI.... The installer would present the user with link to click to take them to the download page for the latest release of the installer. I would likely prevent the install from proceeding. A little finesse. Too much?

Let me know what you think, no rush.

[kytrinyx]

For now, while the v2 website is in beta, we will be releasing the nextercism CLI under the name nextercism.exe (and zip) so that people can test the beta and still use the live site. I don't know if this is relevant to the installer, though.

The installer would present the user with link to click to take them to the download page for the latest release of the installer. I would likely prevent the install from proceeding. A little finesse. Too much?

I'm not sure.

The core problem here is that for the old CLI you want to call the configure command, but for the new one you don't?

[rpottsoh]

The core problem here is that for the old CLI you want to call the configure command, but for the new one you don't?

Correct. See #24, the long and the short of it being that the new CLI will be interactive so the only functions the installer need perform is downloading the correct (32/64 bit windows) CLI for the user, unzip it, and update the PATH. The installer never needs to invoke the CLI. There are other small items, but that is the jist.

Should the installer be modified to install either CLI? The user would be presented with the option of selecting which they want? The fact that each will be in differently named ZIP files makes it easy to differentiate between CLI and NexterCLI.

[kytrinyx]

How about checking the version of the CLI that you download? The URL that you get redirected to when you call /latest will have that in it. If it is 2.x.y then it is the old one, if it is 3.x.y then it is the new one.

The user would be presented with the option of selecting which they want?

No, I don't think that's useful. It should only download the latest official one. (The nextercism cli will be prerelease, so it won't be delivered as "latest").

If people want to be a part of the beta, they will need to download the CLI manually.

[rpottsoh]

I think I am only half following what you are saying.

If people want to be a part of the beta, they will need to download the CLI manually.

The installer will not be used for the new CLI while it is in pre-release. I have no problem with that.

How about checking the version of the CLI that you download? The URL that you get redirected to when you call /latest will have that in it. If it is 2.x.y then it is the old one, if it is 3.x.y then it is the new one.

This is where you lost me. I could update the installer so that when it is runs it can check to see if it is the latest version. If it isn't the latest it would provide a link to click to take the user to the /latest site to download the latest installer. The installer they ran would not try to install the CLI if the installer was not the latest.

Ok... I think I am starting to follow.... Are you asking if the latest CLI happens to be 2.x.y to go ahead and treat it as the old CLI, performing all the install and configuration actions the installer is presently taking, otherwise treat it as though it is new CLI, stopping short at the configuration phase of the install process? This shouldn't be a problem. Do you foresee the latest ever transitioning from 2.x.y to 3.x.y back to 2.x.y (hopefully this doesn't happen 😦 but who knows while trying to transition from the old site to the new.

Starting to ramble. Anyway I can setup the installer to switch on version and take the appropriate installation actions based on the version.

[kytrinyx]

Are you asking if the latest CLI happens to be 2.x.y to go ahead and treat it as the old CLI, performing all the install and configuration actions the installer is presently taking, otherwise treat it as though it is new CLI, stopping short at the configuration phase of the install process?

Yepp, that's exactly it.

The old site will always use 2.x.y and the new site will always use 3.x.y - we won't transition back to 2.x.y. If anything, we would then introduce 4.x.y, which we could update the installer to handle.

[rpottsoh]

This should be coded in absolute terms then? If V2 do this. If V3 do this. Not if V3 and up do this. Correct? This would require that the installer always have an update whenever the CLI increased its major version. I'm fine with it either way. The most control is retained by using absolutes.

[kytrinyx]

I don't think it matters much at this point—let's go with v2/v3-and-up and we can change it if we need to.

[rpottsoh]

@kytrinyx another clarification. I need to know that what the ZIP file names will be for the V3 Windows CLI (32 & 64 bit). I am presuming the ZIP names will be the same as they are now. I thinking this since the Installer will not have access to the V3 CLI until it is passed the pre-release phase and is actually released.

[kytrinyx]

I am presuming the ZIP names will be the same as they are now.

Yes, that is correct.

[rpottsoh]

@kytrinyx now that I have had a chance to try out the nextercism CLI is configure going to become interactive at some point? Right now configure in the v3 CLI is essentially the same as the v2 CLI. I guess I want to make sure we are on the same page on what interactive means. I'm assuming the first time nextercism configure is invoked, the CLI will prompt the user to input their token and input the path to their workspace location. Just tell me to be quiet if configure just isn't there yet. 😄

[kytrinyx]

@rpottsoh configure will not become interactive, but download and submit will interactively ask for information that would normally be set in configure, if we don't have that information yet.

[rpottsoh]

OK. I was assuming the configure would be as well. download and submit makes more sense. I'll keep to the plan as we have it laid out above. It appears, though, that if you want the installer to configure the v3 CLI for the user that that is still an option as long as --token and --workspace persist. The process would be the same as it is now for the v2 CLI.

[kytrinyx]

It appears, though, that if you want the installer to configure the v3 CLI for the user that that is still an option

I'd rather not. Thanks!

[rpottsoh]

@kytrinyx the changes that we have discussed have been implemented and I think I am ready to release. The installer will install v2 and v3 CLIs fine. v2's will be configured and v3's will not. At the conclusion of the v3 install the user is informed to execute the CLI, also a link is available on the screen that links to exercism/docs.

[kytrinyx]

That sounds great, @rpottsoh! Nice work on this ✨

[rpottsoh]

Thanks, it has been fun. Looking forward to doing more.