Sdk: SUGGESTION based on https://deno.land by Ryan Dahl

[cindRoberta]

how about you eliminated pubspec.yaml, turning local downloaded repositories centralized as on Deno? I recommend using deno and get inspired on the runtime practicalities and organization

[mraleph]

There are no plans to move away from current way of managing dependencies.

One important thing to think about when considering Deno's approach, is that Dart _requires_ a single version of the package to be imported into an application, while Deno and node support multiple versions of the same package. This is a fundamental difference - duplicated modules with different versions might actually cause some subtle issues. In node they eventually realised it and introduced peerDependencies to resolve it. It's not really obvious how to naturally fit this into Deno's approach, without requiring programmer to do manual version solving and dependency management - which package manager would otherwise do for you.

I actually believe that as complexity of Deno applications (and complexity of their dependency graphs) goes up they would be forced to introduce some sort of package management - version solving tool.

Another interesting thing to note here is the following text from Deno's manual.md:

It seems unwieldy to import URLs everywhere. What if one of the URLs links to a subtly different version of a library? Isn't it error prone to maintain URLs everywhere in a large project? The solution is to import and re-export your external libraries in a central deps.ts file (which serves the same purpose as Node's package.json file). For example, let's say you were using the above assertion library across a large project. Rather than importing "https://deno.land/std/testing/asserts.ts" everywhere, you could create a deps.ts file that exports the third-party code:

export {
  assert,
  assertEquals,
  assertStrContains,
} from "https://deno.land/std/testing/asserts.ts";

And throughout the same project, you can import from the deps.ts and avoid having many references to the same URL:

import { assertEquals, runTests, test } from "./deps.ts";

This design circumvents a plethora of complexity spawned by package management software, centralized code repositories, and superfluous file formats.

So for larger applications you are more or less forced to create equivalent of package.json - to manage import URLs (and versions embedded into those URLs) in a central location. It's unclear if this is actually a win over package.json - it's just different form of it. And this form requires a more complicated parser to analyse it (compared to package.json).

[mraleph]

FWIW, you could always import Dart libraries over http, so something like this:

// main.dart
import 'https://gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart';

void main() {
  sayHello();
}

actually works since forever.

We just don't do caching of the dependencies - so they are always fully refetched whenever you run the program.

[cindRoberta]

There are no plans to move away from current way of managing dependencies.

One important thing to think about when considering Deno's approach, is that Dart _requires_ a single version of the package to be imported into an application, while Deno and node support multiple versions of the same package. This is a fundamental difference - duplicated modules with different versions might actually cause some subtle issues. In node they eventually realised it and introduced peerDependencies to resolve it. It's not really obvious how to naturally fit this into Deno's approach, without requiring programmer to do manual version solving and dependency management - which package manager would otherwise do for you.

I actually believe that as complexity of Deno applications (and complexity of their dependency graphs) goes up they would be forced to introduce some sort of package management - version solving tool.

Another interesting thing to note here is the following text from Deno's manual.md:

It seems unwieldy to import URLs everywhere. What if one of the URLs links to a subtly different version of a library? Isn't it error prone to maintain URLs everywhere in a large project? The solution is to import and re-export your external libraries in a central deps.ts file (which serves the same purpose as Node's package.json file). For example, let's say you were using the above assertion library across a large project. Rather than importing "https://deno.land/std/testing/asserts.ts" everywhere, you could create a deps.ts file that exports the third-party code:

export {
  assert,
  assertEquals,
  assertStrContains,
} from "https://deno.land/std/testing/asserts.ts";

And throughout the same project, you can import from the deps.ts and avoid having many references to the same URL:

import { assertEquals, runTests, test } from "./deps.ts";

This design circumvents a plethora of complexity spawned by package management software, centralized code repositories, and superfluous file formats.

So for larger applications you are more or less forced to create equivalent of package.json - to manage import URLs (and versions embedded into those URLs) in a central location. It's unclear if this is actually a win over package.json - it's just different form of it. And this form requires a more complicated parser to analyse it (compared to package.json).

as far as I know, this is so easy to solve that it was solved already: put the version in the URL

I believe Ryan Dahl and his team think the same way I do, deps.ts is not turn back to package.json, it's an escape valve if the creator of the module does it in the wrong pattern, not putting the version in the url as it is done on https://cdnjs.com/libraries#

and there is the --reload option to update the local repository

the programming language should set pattters and set good patterns, PHP has bad patterns and gave developers freedom to do the way they want without safety-lock (goto as a example in others) or warning like Javascript, so PHP is a mess (known in my country as a zone)

please, use deno, start with deno -h and compare to pub -h

[cindRoberta]

you don't need to eliminate pubspec.yaml, you can mantain the 2

to the case you show me:

// main.dart
import "https://gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart";

void main()=> sayHello();

---

to cache fragmenteded on .pub-cache, you could do like this:

// main.dart
import "https://gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart" cachefragmentededon ".pub-cache";

void main()=> sayHello();

this would be cached on .pub-cache/https/gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart

---

to cache on a folder inside .pub-cache, you could do like this:

// main.dart
import "https://gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart" cacheon ".pub-cache/module/version";

void main()=> sayHello();

this would be cached on .pub-cache/module/version/test.dart

---

to cache fragmenteded in other folder out of .pub-cache, would be:

// main.dart
import "https://gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart" cachefragmentededon "/home/user/folder/";

void main()=> sayHello();

this would be cached on /home/user/folder/https/gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart

---

to cache in other folder out of .pub-cache, would be:

// main.dart
import "https://gist.githubusercontent.com/mraleph/7f937d8545f247f98de78e323cdbc3f1/raw/4165c1202b5882558952ea1894de5528ece3b41c/test.dart" cacheon "/home/user/folder/module/version";

void main()=> sayHello();

this would be cached on /home/user/folder/module/version/test.dart