`Enso_Project.enso_project` does not work as advertised

[radeusgd]

The documentation says that it

Returns the Enso project description for the project that the engine was
executed with, i.e., the project that contains the `main` method

however in practice, which can be easily confirmed by checking the code - it returns the project associated with the immediate call site.

That means that if I call Enso_Project.enso_project from within the Standard.Base library, it will actually return the project for Base, not the project that is currently running and only calling into Base.

Moreover, the result is cached, so the behaviour of this method depends on where it was called first, for example:

1. Create the following file in Base/0.0.0-dev/src/My_Test.enso:

   import project.Meta.Enso_Project
   
   foo = Enso_Project.enso_project
   

2. Rebuild the engine and run a project with following Main.enso method:

   from Standard.Base import all
   import Standard.Base.Meta.Enso_Project
   import Standard.Base.My_Test
   
   main = 
       IO.println My_Test.foo.name
       IO.println Enso_Project.enso_project.name
   

3. Then run it again swapping the last 2 lines:

       IO.println Enso_Project.enso_project.name
       IO.println My_Test.foo.name
   

The first run yields:

Base
Base

and the second run yields:

testproject1
testproject1

The result depends only on the place where Enso_Project.enso_project was called first.

[radeusgd]

Moreover, the Enso_Project.enso_project call fails if the first time we are calling it outside of Enso:

Assertion_Error.Error 'Should not reach here: callRootNode = org.graalvm.polyglot.Value<Function>.execute. Probably not called from Enso?'
        at <enso> Enso_Project.enso_project(X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Meta\Enso_Project.enso:105:5-52)
        at <java> org.graalvm.polyglot.Value<Function>.execute(Internal)
        at <Unknown Location> related to com.oracle.truffle.host.HostObject.doInvoke
        at <enso> case_branch(X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Enso_Cloud\Internal\Audit_Log.enso:36:25-81)

This is problematic for my use-case as I need to report some audit logs directly from the Java helper libraries. Can we maybe initialize the project info somewhere during Context initialization to ensure that we can guarantee it is also accessible to Java code?

[Akirathan]

Moreover, the Enso_Project.enso_project call fails if the first time we are calling it outside of Enso:

@radeusgd Can you provide a reproducer for that? I have tried to run just the test in https://github.com/enso-org/enso/blob/aa24564bddd19e02f95415c90830a1f18fff2ef5/test/Base_Tests/src/Semantic/Meta_Location_Spec.enso#L41-L44 with enso --run test/Base_Tests/src/Semantic/Meta_Location_Spec.enso "enso_project can be called from Java code" and it succeeds.

[Akirathan]

@radeusgd Feel free to ignore my previous message. I have already implemented a reproducer in https://github.com/enso-org/enso/commit/f50e6e18983dd877ae6dd2dd4305a4ecac5e4955

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-06-07):

Progress: - ydoc merged

• enso_project is derived from the package repository, not from stack trace.
• Initial steps for collecting Oracle GraalVM benchmark data, along with other useful stuff. It should be finished by 2024-06-10.