Derive --in-project from --run source location

[JaroslavTulach]

Pull Request Description

Tired of specifying --run as well as --in-project paths? Let the launcher detect the project for you. According to the packaging structure there is supposed to be package.yaml next to src folder (which hosts .enso source files). Let's traverse parent folders of file specified in --run file argument and if one of them is named src check, if there is also package.yaml sibling. If so, use it as an --in-project argument.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• All code follows the
  Scala,
  Java,
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.

[radeusgd]

Tired of specifying --run as well as --in-project paths? Let the launcher detect the project for you.

This is exactly one of the problems the launcher project is supposed to solve. The engine runner was supposed to just be an internal entry point for the launcher and now we are replicating the launcher's logic within it.

I'm not against that, but let's bear in mind we are duplicating this logic.

1. Maybe we should try to improve the launcher so that you can use it more?
2. Or alternatively, maybe we should just decide that the launcher is deprecated for now and the runner is the primary entry point for CLI (that seems to be the de-facto status right now anyway, just not 'officially' said)?

[radeusgd]

This seems to be +- replicating the logic of
https://github.com/enso-org/enso/blob/develop/engine/launcher/src/main/scala/org/enso/launcher/project/ProjectManager.scala#L34-L37

[radeusgd]

I don't think I understand this message.

please do not use the --in-project option for running projects? What is this option supposed to be used for, if not exactly that?

[JaroslavTulach]

The message has been there for ages.

It is activated when the two options --run project1 --in-project project2 are combined and point to different project.

[JaroslavTulach]

2. Or alternatively, maybe we should just decide that the launcher is deprecated for now and the runner is the primary entry point for CLI (that seems to be the de-facto status right now anyway, just not 'officially' said)?

I have to admit I never understood why you claimed launcher was the primary entry point!? When I joined enso and read contributing docs I hardly ever noticed there is a note about launcher/buildNativeImage. I probably never launched the target myself.

However there always have been notes about buildEngineDistribution and buildProjectManagerDistribution. The files produces by those two sbt targets are entry points for me. Since I joined we even increased the importance of these targets by adding runEngineDistribution and runProjectManagerDistribution and providing debugging documentation based on top of these targets.

Can you explain why you believe launcher is/should be the main entry point?

[radeusgd]

Can you explain why you believe launcher is/should be the main entry point?

I think that was the whole rationale for creating it, otherwise why would it even exist?

It essentially had 2 purposes:

1. managning Enso versions
   i. installing them
   ii. installing the needed GraalVM version for each Enso version, and selecting the right GraalVM java to use (mostly useful for end-users, who may have a different Java version installed as default and would cause Enso to fail to run),
   iii. selecting right Enso version to run based on project settings (which was partially removed in project-manager as we actually wanted to always use 'latest').
2. providing a user-friendly CLI for end users

The idea was that the launcher may provide simple to use and 'smart' commands, like enso run that detects the --in-project settings, while the runner.jar is more of an internal entry point that the launcher can then use to run a particular engine version.

As for the debugging docs, I guess they were never update + they were meant more for internal use so using the internal runner was more acceptable.

I'm not negating that it sometimes makes sense to use the runner as the entry point for development work, it does have some advantages. I'm a bit skeptical about essentially re-implementing the UX improvements we already had for years in the launcher, instead of just using it.

[JaroslavTulach]

I see. Certainly we don't want Enso users to think about the right JVM/GraalVM to use. That has to be addressed somehow and using PATH=$JAVA_HOME/bin:$PATH (as I do right now) isn't the right solution.

[radeusgd]

I see. Certainly we don't want Enso users to think about the right JVM/GraalVM to use. That has to be addressed somehow and using PATH=$JAVA_HOME/bin:$PATH (as I do right now) isn't the right solution.

That's exactly one of the things that the launcher is supposed to solve.

[JaroslavTulach]

I'm not against that, but let's bear in mind we are duplicating this logic.

I guess that's OK. The logic doesn't seem to be in conflict and the new behavior is going to be useful for engine developers.

[Akirathan]

Nice DevX improvement and nice tests, as always.

[hubertp]

LGTM