Is there any way to get the path of the current file?

[mybearworld]

I want to read a file that is in the same directory as the Gleam file that's trying to read it. When using a relative (./) path, it tries to read from /build/dev/javascript/, which is not where the file is located, and it's not being copied over by Gleam.

Is there any way to get the path of the Gleam file from the Gleam program, so that this is doable?

Thanks!

[lpil]

There is not, no. Gleam isn't a scripting language so there's no practical definition of "current file". The source code of the program may not be present on the computer running the application at all.

[lpil]

It wouldn't be useful for a test framework as you'd have the path to the test framework file and not the path to the test.

[oderwat]

I have code like this right now (this is from tests of the test framework):

 mxtest.start()
  |> mxtest.funcs(
    mxtest.Inorder,
    // This could be "this file" and used to auto discover all tests with some name pattern or even type signatures
    mxtest.module_funcs_from_file("test/mxtests_file.gleam", string.ends_with(
      _,
      "_postfix_foo",
    ))
      |> mxtest.create_func0_list,
  )
  |> mxtest.finish()

pub fn find_funcs_test() -> Nil {
  mxtest.funcs_from_file("test/mxtests_file.gleam")
  |> should.equal(
    // This could be "this file" and used to auto discover all tests with some name pattern or even type signatures
    mxtest.FileModuleFunctions("test/mxtests_file.gleam", "mxtests_file", [
      "test_func_with_postfix_foo", "test_func1_with_fixture_foo",
      "test_func2_with_fixture_foo", "not_tested", "autotest_test",
    ]),
  )
  Nil
}

They are used to building tests that have context / fixtures and can run in order or in parallel. I also prepared timeout, and remote node testing. But right now I still work on the API and helper functions to setup/cleanup temp dir, file structures, container start and some other stuff we need for our CI chains.

[lpil]

You're already using FFI there to do the test discovery so you could use FFI to get the module.

Any feature that needs FFI to be used isn't a good candidate for addition.

[oderwat]

Not sure if that would get me the path of the source for a module inside a subdirectory of test. I have to experiment with that. But I do not care that much. This is very special as I said, and it works already "good enough".

I think having a compiler native _FILE_, _LINE_ could be nice as part of an error type. Using it as string for logging purposes could also be useful. But I guess this is probably really hard to implement.

I am not sure what you mean with FFI and what addition you talk about? A lot of packages are using FFI. What has this to do with adding a file / line "pseudo constant" to the compiler?

[lpil]

As I explained it wouldn't be useful for those things unless you use FFI, and if you use FFI you don't need it. Gleam is a very small language where every feature is intended to have maximal impact. We don't add things unless they dramatically improve the experience of writing Gleam and solve multiple major problems.

[vistuleB]

I want to read a file that is in the same directory as the Gleam file that's trying to read it. When using a relative (./) path, it tries to read from /build/dev/javascript/, which is not where the file is located, and it's not being copied over by Gleam.

Is there any way to get the path of the Gleam file from the Gleam program, so that this is doable?

Thanks!

Coming on this late. Out of curiosity, what were you using to read the file?

[lpil]

Simplifile is the normal file system package