Native library support for Pub

[DartBot]

This issue was originally filed by [email protected]

---

Pub should define a layout convention for extensions with native library components (https://github.com/sam-mccall/dart-sqlite is a simple example).

Pub should be able to build the native components as part of installation, on systems with the appropriate toolchain available.

Pub should also be able to share the resulting platform-specific binary package, so that other users don't have to compile it.

[sethladd]

Agreed!

---

cc @munificent.
Removed Type-Defect label.
Added Type-Enhancement, Area-Pub, Triaged labels.

[sethladd]

cc @whesse.

[whesse]

We have adopted the convention of putting shared libraries in the same directory as the extension, without thinking too much about it. We also support relative paths and absolute paths.

Soon we should reevaluate where the native libs should go, thinking about deployment and security issues as well. Do you think the current solution is the right one?

[DartBot]

This comment was originally written by [email protected]

---

.so-in-the-same-directory has been very convenient for me, easy to understand, and keeps the library directory self-contained.

I'd like to keep it, if it doesn't complicate security or pub too much.

[DartBot]

This comment was originally written by [email protected]

---

A "Dartify" step could be nice at pull time in Pub ..

[munificent]

Added this to the Later milestone.

[munificent]

Removed this from the Later milestone.
Added this to the M1 milestone.

[munificent]

Removed this from the M1 milestone.
Added this to the Later milestone.

[munificent]

This looks very cool, Andrew. We aren't working on native extension support right now, but when we get to it, I'll take a closer look at what you have here. Thanks!

[sethladd]

Issue #6290 has been merged into this issue.

[munificent]

Issue #4674 has been merged into this issue.

[DartBot]

This comment was originally written by @tomaszkubacki

---

Any status change for this issue ?

[munificent]

Sorry, but there's no update here.

We've been primarily focused on client-side Dart applications which (naturally) do not allow native extensions. When the larger Dart team makes a shift towards server-side applications, we'll be able to start looking into this.

[munificent]

Can you provide some information about any specific timeline?

Unlike many companies, Google isn't very timeline oriented. We try to stay flexible so that we can respond quickly to changing circumstances. This means that we have a rough idea of what we're working on in the next few months, but little beyond that. Even within that shorter time span, we are rarely committed to work on something. Priorities change quickly.

Right now, our focus is getting the transformer and development story solid and fully integrated into the Editor and the other corners of the Dart developer experience. That will keep us busy at least for the next few months as we add features to make transformers more expressive and chase down bugs.

Once that settles down, I expect we'll put a bit more focus on server-side Dart. Right now, it isn't easy to run a command line application exposed by a package, so we intend to fix that.

So far, we haven't had many requests for native library support in pub compared to other things users are asking for, but once other aspects of supporting server-side apps in pub are working smoothly, that will be a natural time to start thinking about native libraries.

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[kasperl]

Removed Oldschool-Milestone-Later label.

[DartBot]

This comment was originally written by @seaneagan

---

Adding a use case:

issue #21337

[DartBot]

This issue has been moved to dart-lang/pub#39.