Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native assets on pub #3693

Open
dcharkes opened this issue Dec 12, 2022 · 3 comments
Open

Native assets on pub #3693

dcharkes opened this issue Dec 12, 2022 · 3 comments
Labels
P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug

Comments

@dcharkes
Copy link
Contributor

We've been discussing this for a while, but I wanted to open an issue on the pub repo to track this.

In the context of

we should support uploading precompiled native assets to pub, so that pub can download them for the required target architectures.

If package authors precompile binaries, the current way of working is to either

  1. host them on a third party server and download them using bin/setup.dart for Dart standalone and in the native build scripts for FFI plugins in Flutter, or
  2. push them all to pub (if you're under the 100MB package limit).

This has several drawbacks.

  1. If the third party server goes down, packages don't run anymore (for option 1).
  2. The package developer needs to have the binaries for all target architectures on a single machine when doing dart pub publish (copying over Mac binaries over to Linux for example) (for option 2).
  3. pub get downloads for all target architectures (for option 2).

It would be better if binaries can be uploaded to pub.

The best workflow would be if the binaries can be build on the (Github) CI, and then automatically uploaded to pub. Together with the commit-tagging-leading-to-releases-on-pub. This way package authors don't have to have access to MacOS, Linux and Windows machines to cover all target architectures.

In order to work in this direction we need to solve many design questions. Some questions that come to mind:

  1. How does authentication/security work?
  2. What is the list of target architectures. In the current prototype, it is OS x Architecture, but distinguishing iOS device from iOS simulator due to the different SDKs being linked in.
@mosuem
Copy link
Member

mosuem commented Feb 1, 2024

Any updates on this?

For package:intl4x, we need to download the correct binary file in the build.dart. pub.dev would be the obvious candidate to host these binaries needed to run a package. Currently, I use a 3P solution from @oprypin.

Ideally, these binaries could be tied to the package version, and include some sort of signing or similar to increase trust in the downloaded binaries.

@mosuem
Copy link
Member

mosuem commented Mar 4, 2024

Conclusion of an offline talk with @sigurdm and @jonasfj: This will not be supported anytime soon, as adding potentially large files to pub.dev and associating them with releases poses many challenges.
There is a viable alternative: Use Github to create binaries with a release and check their hash in the consuming Dart package.

@mosuem mosuem closed this as not planned Won't fix, can't repro, duplicate, stale Mar 4, 2024
@dcharkes dcharkes added the P3 A lower priority bug or feature request label Mar 4, 2024
@dcharkes
Copy link
Contributor Author

dcharkes commented Mar 4, 2024

This will not be supported anytime soon

That's reason for giving it a p4 or p3 label, not for closing it correct?

@dcharkes dcharkes reopened this Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug
Projects
Status: No status
Development

No branches or pull requests

3 participants