I think this is a duplicate of 5950

This seems to be fixed now, possibly as a result of the recent isolate refactor.

Added Fixed label.

Never mind, I think my attempted reproduction was flawed. This is still an issue.

Added Triaged label.

I don't think that relative to the working directory makes sense.
If I have main.dart and long_running.dart in the same directory and main.dart spawnUris long_running.dart, then I want to be able to just spawnUri("long_running.dart").
If I had launched the entry-point (main.dart) with a different working-directory this would fail.

Every other core library API that takes a path treats it as relative to the working directory. It's confusing and inconsistent to have this one API be an (undocumented!) exception.

What's more, this behavior is rarely going to be useful at all. Most people writing code complex enough to use isolates are going to be splitting their code across multiple libraries. This means that they can't safely assume -- and may not even know -- where the entrypoint is.

In the few cases where the author knows the location of the entrypoint and wants to load something relative to that, it's easy to use [Platform.script] to do so. Please don't sacrifice the comprehensibility of the API for that narrow use case.

I'm not saying that the entry-point is the correct solution, but the current working directory isn't either.
We have to support the use-case where a library wants to spawn a service with a dart-file that is in it's directory (or relative to it).

What we probably need is a way to get to the current script-directory. In which case the program would need to explicitly use that directory.
In that case we could use the current working directory.
Until we have solved this important use-case, we are not going to make any decisions.

Every other platform API that takes a path is in the I/O library.
The I/O library is really a Posix operating system interface, and as such has a notion of current working directory (or directories at all).

The isolate library works in a browser as well, and the only fixed point that a library has in there is the URL it was loaded from.

When you have files and I/O, you can easily construct a file:-URL from a path, and get access to the current working directory. That means that letting relative URLs be relative to the library will work in all cases, and when you have files, you can also make them relative to the current working directory, you just have to do it explicitly.

I think the current spawnUri is the best we can do, and I don't even think it's bad :)

It doesn't support the use-case from comment #­6. So we need to find a fix for that.
I'm not sure if there is an easy fix, though. In particular we also want to make this work after a dart2dart or dart2js compilation.

Ah, yes. For the entry library, it works, but for other libraries it doesn't.

It would be great if it worked relative to the library calling it, but that's probably unimplementable (or too fragile to ever work correctly).

A better solution would be to somehow give a library access to its own location URL
(potentially without mirrors). And not as PATH :)

I'd certainly like to see issue #1145 fixed, but I still think the correct way to handle this case is to treat the URI as relative to the current base URI. I don't think it's at all correct to say that the notion of a "working directory" is specific to console apps -- relative URIs have a canonical meaning in the browser just as much as they do on the console. They're relative to the current window's URL. We already encode this notion in [Uri.base]. If we're going to claim that spawnUri takes a URI, it should resolve that URI in the canonical way.

I don't think we can change this now without breaking code.
Using Uri.base as the base URI would be a good choice, but changing the behavior of Isolate.spawnUri at this point is not a good idea.

Added this to the 2.0 milestone.

Issue #5950 has been merged into this issue.

Can we do this as part of 2.0?

Are any further changes planned here for 2.0? @lrhn @a-siva

If the dart:isolate library becomes VM-only, then referring to current working directory is actually meaningful.
The risk of breaking existing code hasn't changed, though.

There are no plans for changing dart:isolate in Dart 2.0.

Removing the milestone, since this isn't happening for 2.0.