lfc no longer works without a network connection

[edwardalee]

lfc no longer works without a network connection. Perhaps we need a command-line option to skip the build and just use the most recent lfc? Error message is below.

EALMAC:C eal$ lfc src/Junk.lf 
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :core:generateXtextLanguage FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':core:generateXtextLanguage'.
> Could not resolve all files for configuration ':core:mwe2'.
   > Could not resolve org.eclipse.emf:org.eclipse.emf.ecore:[2.20.0,3.0.0).
     Required by:
         project :core > org.eclipse.xtext:org.eclipse.xtext.xtext.generator:2.28.0 > org.eclipse.emf:org.eclipse.emf.codegen.ecore:2.20.0
      > Failed to list versions for org.eclipse.emf:org.eclipse.emf.ecore.
         > Unable to load Maven meta-data from https://repo.maven.apache.org/maven2/org/eclipse/emf/org.eclipse.emf.ecore/maven-metadata.xml.
            > Could not HEAD 'https://repo.maven.apache.org/maven2/org/eclipse/emf/org.eclipse.emf.ecore/maven-metadata.xml'.
               > repo.maven.apache.org: nodename nor servname provided, or not known

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/8.1.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 9s
8 actionable tasks: 1 executed, 7 up-to-date

[erlingrj]

@cmnrd We ran into issues with this also for lingo. A simple fixed seems to be rename the gradle script to e.g. lfc-dev or lfc-gradle or something. And then move the old lfc executable back into bin. There are other useful executables in the bin directory so people will put it on the system path and then lfc no longer works without internet connection and lingo also runs into issues.

Was there another reason, except convenience, to have the gradle script be at bin/lfc?

[cmnrd]

This is the expected behavior. As of our documentation, the scripts in bin/ in the root directory invoke our cli tools through gradle and, unfortunately, gradle needs an internet connection. If the old behavior is preferred (invoke the cli tools of the last build directly), people can use the scripts in build/install/lf-cli/bin/ instead. Thus, no cli switch is needed. For convenience users can simply put their preferred version on the path.

There are other useful executables in the bin directory so people will put it on the system path and then lfc no longer works without internet connection and lingo also runs into issues.

I don't understand this comment. There are only the scripts for lfc, lfd and lff in bin.

As far as I understand from Tassilo, it would be possible to circumvent the issues with lingo by passing the JSON via stdin (also through Gradle). So a rename wouldn't be necessary.

If people think it would be less confusing when the scripts in bin/ have different names then the ones in build/install/lf-cli/bin/, I would be open for that discussion.

[erlingrj]

Tracing utilities are also installed to the bin directory.

[edwardalee]

Hmm. This does not seem good to me, particularly in view of #1874 (Gradle build is slow again). Running lfc through gradle is convenient for those of us developing LF, but a significant inconvenience for those using it. And I watched a lot of movies on the flight back from Paris because I couldn't run lfc... (or didn't know that I could if I found the hidden binary).

I would suggest that the gradle invocation of lfc should have a different name, e.g. lfcd ('d' for 'developer'), and that 'lfc' should be just the latest executable. And all the executables should go in bin.

[lhstrh]

Hmm. This does not seem good to me, particularly in view of #1874 (Gradle build is slow again). Running lfc through gradle is convenient for those of us developing LF, but a significant inconvenience for those using it.

I just want to emphasize that Gradle is currently not involved in any of the binaries that we distribute. Gradle produces them but is not required for running the binaries it produces. Users will not be cloning the repo and invoking the scripts in bin; only developers do this.

[lhstrh]

Tracing utilities are also installed to the bin directory.

We currently don't release or distribute the tracing tools. Only a developer would obtain them but cloning the lingua-franca repo. Everything that sits or is put in bin in the lingua-franca repo is for developers, not users.

[cmnrd]

I would suggest that the gradle invocation of lfc should have a different name, e.g. lfcd ('d' for 'developer'), and that 'lfc' should be just the latest executable. And all the executables should go in bin.

I feel like there is still some confusion about the locations of lfc. We have two "views":

• bin/: This is the developer version of lfc that requires gradle. Only someone cloning the repo sees and uses this version.
• build/install/lf-cli/bin: This is the distribution (or release) version of lfc. It is a script generated by Gradle (i.e. it is a build artifact). This script does not require gradle to run. We distribute it to our users and also developers can add it to their path if they prefer to use the last build artifact instead of running lfc through gradle.

It is not my preference, but I would be Ok with renaming the scripts in bin so that some disambiguation is possible if both locations are on the path. However, this could also have some negative implications like that we cannot use the developer lfc in conjunction with lingo.

Even if we change names, the correct location for the release lfc remains in build/install/lf-cli.

Another idea might be to rename bin to dev or dev-bin to make it clear that it contains developer scripts.

Tracing utilities are also installed to the bin directory.

What does it mean they are installed in bin? There are no tracing tools checked in to our git repo in bin. Do you mean they are copied locally somehow? If that is the case, then this "install" mechanism shouldn't exist in the first place, and it seems more like a strange hack.

[edwardalee]

How would you suggest handling the tracing utilities?

[cmnrd]

Generally, I think they should be in another repo (#1491).

I don't know which scripts we are actually talking about, where they are located, and what gets installed in bin/ (and why). Is this documented somewhere? Without this information it is hard for me to make specific suggestions on how to handle the tracing scripts within the LF repo.

[cmnrd]

Ok, I found some documentation here. It doesn't say why, but apparently make install in util/tracing installs a couple of scripts and executables in bin/. However, bin/ isn't a place for distributing build artifacts (it never was). My suggestion would be to simply install those artifacts in util/tracing/ or util/tracing/bin/. This would make the util/tracing directory a self-contained subset of the LF repo, with its own tooling (make), that does not need to interfere with the rest of the repo.

If we decide to go with this, we should also close #1491.

[cmnrd]

Closing this. The trace tools got moved out (#1948) and the scripts in bin got renamed (#1988 and #1995).