Can't get path to current script

[munificent]

When writing Dart scripts that read other files, it's helpful if you can identify that file with a path that's relative to the script itself. Right now, I don't think there's a way to get that in Dart. Instead, paths are always relative to where Dart was invoked from. This causes problems if you want to invoke the same script from different paths and have it still be able to reliably find files.

For example, I have a unit test (utils/tests/dartdoc/src/dartdoc_tests.dart) that wants to load a file in its same directory (dummy.dart). This unit test is run both through test.dart and frog's presubmit.py from different paths. Short of "let me see if it's here? no, how about here?" kind of hacks, I don't know of a clean way to support that.

[whesse]

Set owner to @whesse.
Added Area-Library, Accepted labels.

[DartBot]

This comment was originally written by ngeoffray@google.com

---

Is that a duplicate of Issue #409?

[whesse]

Added Duplicate label.
Marked as being merged into #409.

[munificent]

Yes, sorry. I didn't find the other bug when I searched to see if this had already been reported.

[munificent]

After thinking about this some more, I don't believe this is the same issue as bug #­405. My understanding is that that bug is for:

  // a/b/main.dart
  #import('c/d/other.dart'); // or using #source
  main() => other();

  // c/d/other.dart
  other() => print(new Options().script);

  $ dart_bin ./a/b/main.dart
  a/b/main.dart

What I want here is the ability to get this:

  // a/b/main.dart
  #import('c/d/other.dart'); // or using #source
  main() => other();

  // c/d/other.dart
  other() => print(???);

  $ dart_bin ./a/b/main.dart
  a/b/c/d/other.dart

Something like FILE in C++, or file in Python.

My specific use case is I have a test script that needs to load some test data from a file. It knows where the file lives relative to itself. It does not know where it lives relative to where the user is invoking dart or relative to where the main script that ultimately #imports it is.

Re-opening this bug since as far as I can tell the issue is still valid.

I need this to work in frog too. Should I file a separate bug for that?

---

Added Triaged label.
Marked as being merged into #.

[whesse]

It seems to me that this would be a URI property of a library, saying where the library is loaded from. Is this part of reflection?

I don't see it as likely that a file that is included by #source would be able to find its location, but a library imported by #import may be able to know its URI.

---

cc @gbracha.
Removed Type-Defect, Area-Library labels.
Added Type-Enhancement, Area-Language labels.

[DartBot]

This comment was originally written by andrew.penne...@gmail.com

---

file / $0 are highly desirable. Please find a way to do this.

[gbracha]

I think this is really about the reflection API. Basically, what URI was used to import the library.

---

Added Accepted label.

[gbracha]

Unfortunately, the URI may not be available after deployment, tree-shaking etc. So we cannot rely on it. We may want a different solution to get at resources bundled with the application.

---

Added WontFix label.

[munificent]

The primary use case for this is command-line scripts that need to find other files relative to themselves, so I'm OK with it not being available for deployed or tree-shaken apps.

[nex3]

This is currently blocking Pub's ability to install packages from the SDK without forcing the user to manually specify the SDK path. Please re-open or suggest an alternative that will be available in the short term.

[gbracha]

So, if this is strictly for server side apps, why not write a native function?

[nex3]

Three reasons.

1. The feature is widely useful, and so makes sense as part of the core Dart distribution.
2. Distributing native code is much more difficult than distributing plain Dart code, which is a major consideration for the scripts and libraries that would be using this.
3. As far as I know, the embedding API doesn't have access to the path of the currently executing Dart file anyway.

[iposva-google]

Nathan, I do not understand why the executable() in the Options interface is not good enough for what you need.

[nex3]

The Options.executable returns the command-line invocation used to run the current script. What I'm asking for is a way to get the path of the current Dart file. Bob gave a good example above of the functional difference between the two.

In practical terms, the return values of Options.executable and Options.script only provide the ability to figure out where the Dart executable or the script entrypoint are. Neither of these suffice for all the use-cases of file. It's important that a library be able to figure out where it exists in the filesystem so that it can (for example) load resources from its installed directory.