[IDEA] Lingo Install

[tanneberger]

lingo install <nightly/stable>

to install latest lingua-franca toolchain.

[lhstrh]

lingo install implies to me the installation of a package (in the cwd if no argument is supplied), so I would invent a different syntax for this. How does Rust manage the installation of rustc? Is there any coupling between cargo and rustc in terms of version numbers or cargo pulling rustc from somewhere?

[erlingrj]

install is probably best reserved for installing LF binaries. But it would be great to have lingo manage the lfc installation. I was thinking something in the lines of

> lingo toolchain install 
... Installs latest stable
> lingo toolchain install nightly
.. Installs nightly.
> lingo toolchain install nightly23052023
.. Installs specific nightly
> lingo toolchain which
lfc nightly14052023
lfc nightly23052023
lfc v0.4.0
*lfc v0.5.0
.. Shows installed lfc version and marks the one it defaults to
> lingo toolchain set-default lfc_v0.4.0
... changes the default 
> lingo toolchain remove lfc_nightly14052023
... Removes a specific toolchain

[lhstrh]

I like this suggestion!

[axmmisaka]

I'll work on this as this will be used by the playground, I want to learn rust, and I need some time to relax from banging my head on mutation......

This is what I will propose, where I copypastaed from nvm:

> lingo toolchain install # Installs latest stable
> lingo toolchain install v0.3.0 # Installs stable v0.3.0; stable versions start with "v"
> lingo toolchain install nightly # Installs latest nightly. We currently don't store nightly from previous days, so only this command will work
> lingo toolchain install 20230630 # Installs nightly built on 2023/06/30; nightly versions are yyyyMMdd, not and cannot implemented as of now
> lingo toolchain uninstall v0.4.0 # Remove stable v0.4.0 
> lingo toolchain use 20230630 # Use nightly version 20230630 
> lingo toolchain cache dir # Display the place lingo toolchain puts lf executable; as of now it will not be configurable and always be $HOME/.lingo/toolchain/; but I think in the future we could use arg/env variable to specify
> lingo toolchain cache purge # Remove all downloaded lf
> lingo toolchain list # Display all local lf releases available
> lingo toolchain list-remote # Display all remote lf releases that one could download

[axmmisaka]

Actually, after a second thought, do we want it to build upon lingo, or with python as a separate script? cargo does not have an option to install rustc but instead it's handled by rustup; the same for npm and node. I came across this idea as I write lingo install stuff. It involves un-taring and downloading, which is kinda weird to be handled by lingo with rust. What do you think? I can definitely continue on this path......

[lhstrh]

Actually, after a second thought, do we want it to build upon lingo, or with python as a separate script? cargo does not have an option to install rustc but instead it's handled by rustup; the same for npm and node.

This is a good point... Maybe we should keep it separate from lingo? I'm not sure that we need to involve another implementation language though...

[axmmisaka]

Actually, after a second thought, do we want it to build upon lingo, or with python as a separate script? cargo does not have an option to install rustc but instead it's handled by rustup; the same for npm and node.

This is a good point... Maybe we should keep it separate from lingo? I'm not sure that we need to involve another implementation language though...

Another reason I think that would be a good idea is like rustup, we could have that script setup lingo as well.

[lhstrh]

Should we go that route, what would be a good name?

[axmmisaka]

Should we go that route, what would be a good name?

I'm thinking lfli: it means "Lingua Franca Live Installer" or "Lingua Franca Language Instructor"

[erlingrj]

I think I am still in favor of having lingo as the one-stop shop for lingua franca, which includes managing the lfc installation. Are there other good reasons for introducing a second tool, I am not convinced that Rust is a bad language for doing this. I am sure that cargo and npm have good reasons though, but what are they, and do they apply to us?

[axmmisaka]

Are there other good reasons for introducing a second tool

One that I could think of is to offer a minimised way to easily install the lf toolchain, i.e. lingo and lingua-franca. Like npm with node and cargo with rustc; lingo should depend on lingua-franca but not the other way (it is reasonable to run lf standalone, but not lingo); and it is not a reasonable way for me to ask users to install lingo first.

Also, if there's changes in lingua-franca that caused changes in lingo, a standalone lfli could switch version of both, while lingo can only choose among versions of lf that it supports.

I am not convinced that Rust is a bad language for doing this

Sorry, just to clarify, rust is not a bad language for this purpose, it's just that 1. rust is too powerful for these simple tasks (i.e. downloading and making symlinks) and 2. these OS-related operations are typically carried out by scripting languages (but rust does have a powerful os package) In fact, rust is one of the "good" languages to do this, since it is statically linked and does not require other dependencies to run.

Another thing to consider for the future is that, like rust, if we publish lingua-franca and lingo to a package repository, then it doesn't make much sense to let lingo handle installation of a (potential user version of) lingua-franca. In that case, users could choose to use lfli or apt, just like with rust they choose between rustup and apt.

[axmmisaka]

I have an working example here: https://github.com/axmmisaka/lingua-franca-lfli If we decide to move onto the lingo path I also have a branch that is WIP; but I need some more time working on mutations......

[cmnrd]

We should definitely avoid introducing another language for our tooling. We already have a lot of heterogeneity. If anything, the goal should be to reduce the languages involved. Maintaining Python tools is a mess... and after all rustup is also written in Rust.

At the moment I don't see a good reason to introduce yet another tool. A separate installer would make sense if we would want to manage multiple versions of lingo and lfc. I don't think we are there and my vote is on keeping things simple for now. With respect to a version of lingo installed via the package manager, lingo toolchain install could still make sense to install a newer version of lfc in the user space.

[tanneberger]

I am personally also prefer lingo install over another tool (lfli). RustUp ist just a tool that installs a different version of cargo and rustc. I personally think it would be way more elegant if lingo can manage itself.

I for example have the following vision. That u for example can also specify if required the lfc version of your lf project and lingo would locally install lfc as a build artifact in your project. For example, this feature would be probably very beneficial to the lingua-franca project, because your api in not fully stabilized yet.

Furthermore, I full support the philosophy that we went to so far with that lingo should be the one-stop shop for all your lf development needs. And this in my opinion includes installing and managing lfc installation. I don't believe that lingo should be the exclusive way to install lfc because your operating system/package manager has this job. But it should definitely support, quickly download the newest and hottest nightly release.

Lingo -> Quality of Live Build Tool LFC -> Just the Code Generator

[axmmisaka]

We have https://github.com/lf-lang/installation now.

One situation I found lingo install might be useful is when we want to install lingua franca locally for that project. Since LF is under rapid development where backward compatibility might not be a primary goal, I could imagine if people want to use an older version of LF for a specific project?

[cmnrd]

Yes, I think this is also what @revol-xut meant above. Lingo should be able to manage the version of the LF code generator (and probably also the runtimes once they have independent releases) required for a specific project.