search

dart-lang / pub

The pub command line tool
https://dart.dev/tools/pub/cmd
BSD 3-Clause "New" or "Revised" License
1.04k stars 224 forks source link

Native assets on pub #3693

Open dcharkes opened 1 year ago

dcharkes commented 1 year ago

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 commented 7 months ago

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 commented 6 months ago

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.

dcharkes commented 6 months ago

This will not be supported anytime soon

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