What about Packaging the build binaries?(application distribution) HOW TO in flutter desktop embedding

38 views
Skip to first unread message

michel...@gmail.com

unread,
Sep 2, 2019, 11:58:35 PM9/2/19
to Desktop Embedding for Flutter
I'm starting to try out Dart and Flutter, I find it interesting. But I'm not sure about it. Also, it's an incomplete project (under construction).

What worries me is how the whole process would work until the final binary packaging and installation.

With electron we have electron-forge, electron-builder and electron-packager. They give us the option to build for all platforms (except if you are on windows, not build for MacOS). And there are also packaging options. Like DMG, PKG, BUT, DEB, RPM, APK, NSIS, AppX, Snap and so on.
However, I have not found anything like it until then. I wonder if it already exists or if there are any plans.

Cheers.

Stuart Morgan

unread,
Sep 3, 2019, 12:49:05 PM9/3/19
to michel...@gmail.com, Desktop Embedding for Flutter
You've touched on a few different things; I'll try to address each one separately. I'm not very familiar with Electron, so if my understanding of one of the tools you've mentioned is incorrect please let me know.

- Building a self-contained folder (electron-packager): Even at this very early stage, all the runners in FDE are already configured to do that. As I've mentioned on the list before, if you take the directory created by building on Windows or Linux, moving it to another machine should work fine (although as I've stressed before, actually distributing things at this stage would be very premature; only macOS even uses a release build of the Flutter engine). So for this aspect, it seems like `flutter build` already does what you want.

- Cross-compilation: Cross-compiling native desktop applications is a much, much harder problem than packaging cross-platform JS with a prebuilt executable. We currently have no plans to support cross-compilation. If someone has a concrete proposal for doing so and is interested in building it out it could certainly be considered, but it would be a significant undertaking. E.g., it would almost certainly require that Flutter completely manage the entire native toolchain installation process, which has far-reaching implications.

- Packaging (electron-forge, electron-builder): From what I can see, these are community efforts, not part of Electron itself. I think that's the right model for Flutter as well. There are many options for packaging and distributing desktop applications, and Flutter applications shouldn't be particularly unusual, so any of those existing solutions should be applicable directly to applications built with Flutter. If people find it useful to write/maintain/distribute specific adaptors that handle the details of, say, building a Snap from the Linux build output, great! But I don't think that would be part of Flutter itself.

-Stuart
--
You received this message because you are subscribed to the Google Groups "Desktop Embedding for Flutter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-desktop-embe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flutter-desktop-embedding-dev/6ef26f09-757d-4e7d-86bb-1e53adec1668%40googlegroups.com.

Chris Sells

unread,
Sep 3, 2019, 3:25:07 PM9/3/19
to Stuart Morgan, michel...@gmail.com, Desktop Embedding for Flutter
Stepping back a little, from a product point of view, our current goal is to make sure that you can pour the output of the 'flutter build' process for desktop targets into whatever mechanism for distribution you'd care to use, e.g. MSI files, DMG files, ClickOnce, DEB files, deployment to the Microsoft or Apple stores, etc. We don't have any replacement distribution or update technology on the roadmap for Flutter beyond what is already provided for each platform natively.

As Stuart says, it would be great to have community involvement for such a feature, e.g. a tool that would produce an MSI for Windows, a DMG for macOS and a DEB for Linux.


michel...@gmail.com

unread,
Sep 3, 2019, 5:56:48 PM9/3/19
to Desktop Embedding for Flutter
Thanks, guys for the answers. In part, not all questions were answered.

The main question was "I wonder if it already exists (something done) or if there are any plans." and "What about Packaging the build binaries? (application distribution) HOW TO in flutter desktop embedding" - With this in mind, I wonder about information more in "how to" other than general explanations.

I know that the tools I've mentioned come from the community. But that's not the point. I wanna know if there's something similar to Flutter Desktop and recommendations.

First @Stuart Morgan

"all the runners in FDE are already configured to do that."
me: There's a documentation for that? and what exactly means "FDE"? is it clear? Also, I would like to understand the structure, what we can move or not in each OS build.

Also, what are the general recommendations? How do we change icons? how do we add metadata? and so on.

"As I've mentioned on the list before" 
me: You've mentioned where? not sure if you are mentioning some other conversation that I'm not aware of.

"moving it to another machine should work fine"
me: Okay, but feels a bit messy and unprofessional to deal like this. In the mobile world is easy, we have e.g. APK installation built-in.

"these are community efforts, not part of Electron itself. I think that's the right model for Flutter as well."
I understand that this coming from community is predictable and comfortable. But I see that flutter roadmap aims to make it simple and easy to use. Not sure if this is true to flutter desktop.

BTW. Things like cross-compiling are pretty normal in GoLang for example. Go was made by Google, So that means the know-how is at home. You guys don't talk to each other? :P

In part, the cross-compiling could be solved by using Docker container and scripts. Making Flutter desktop standalone images for Docker would be handy to build from MacOs to all others, from Linux to Windows, and in Windows to Linux binaries. Only Mac couldn't be possible cuz it's a proprietary thing. However, this is not a simple task for newbies.

Now @Chris Sells

Okay, seems like we have to wait or digging something. But also there are points in my above comments that you could clarify, as you've touched it too.

Cheers.

Stuart Morgan

unread,
Sep 3, 2019, 8:15:57 PM9/3/19
to michel...@gmail.com, Desktop Embedding for Flutter
On Tue, Sep 3, 2019 at 2:56 PM <michel...@gmail.com> wrote:
The main question was "I wonder if it already exists (something done) or if there are any plans."

The short answer is that Flutter-desktop-specific solutions for end-user packaging do not currently exist (they would be premature at this point), and Chris covered the extent of our plans on this front.
 
"all the runners in FDE are already configured to do that."
me: There's a documentation for that? and what exactly means "FDE"? is it clear? Also, I would like to understand the structure, what we can move or not in each OS build.


There is no documentation for the build output yet. Per the bold warning in the README: "The code here is not stable, nor intended for production use."; given that, documenting how to distribute the build output is not currently a priority. But to summarize the current state:
- On macOS, the .app is self-contained.
- On Windows and Linux, the directory containing the executable is self-contained, and should be movable. That directory contains the executable, .dll/.so's for Flutter and plugins, and the Flutter assets.

Also, what are the general recommendations? How do we change icons? how do we add metadata? and so on.

There are currently no recommendation on customizing anything at the level of the native project; given that the projects aren't currently stable, any such customization would be very fragile right now.
 
"As I've mentioned on the list before" 
me: You've mentioned where? not sure if you are mentioning some other conversation that I'm not aware of.

In previous threads on this mailing list where people have asked about moving the built application to another machine. I don't think those threads went into any more details that what I've said in this thread though, so I wouldn't worry about looking for them.

"moving it to another machine should work fine"
me: Okay, but feels a bit messy and unprofessional to deal like this. In the mobile world is easy, we have e.g. APK installation built-in.

I'm afraid I don't understand what you think is unprofessional here. You pointed to electron-packager as part of the toolset for managing Electron builds, which as far as I can tell goes to the level of creating a self-contained directory and then stops (letting other solutions take over from there); I was explaining that 'flutter build' does the same thing.

I'm not suggesting that zipping a directory and distributing that to end users is the right way to distribute an application, just as electron-packager doesn't recommend using its output for direct distribution.
 
"these are community efforts, not part of Electron itself. I think that's the right model for Flutter as well."
I understand that this coming from community is predictable and comfortable. But I see that flutter roadmap aims to make it simple and easy to use. Not sure if this is true to flutter desktop.

I'm not sure what your conclusion that we're not interested in ease of use is based on specifically, so I'm not sure how to reply here other than to say that Flutter has the same core philosophies on desktop as on mobile. Specific requests on ease of use are welcome (with the understanding that it's very much an early-stage work in progress; things like documentation of how build output is structured are obviously going to be important, but also not on the immediate roadmap).
 
BTW. Things like cross-compiling are pretty normal in GoLang for example. Go was made by Google, So that means the know-how is at home. You guys don't talk to each other? :P

Please try to keep comments constructive. I didn't say we have no idea how cross-compilation works, I said that supporting it would be a substantial undertaking, and not within the current architecture of Flutter in general.

Also, I suspect that cross-compiling Go code that calls out to Win32 or GTK or AppKit APIs to build GUI apps is not especially common (certainly not AppKit).
 
In part, the cross-compiling could be solved by using Docker container and scripts. Making Flutter desktop standalone images for Docker would be handy to build from MacOs to all others, from Linux to Windows, and in Windows to Linux binaries. Only Mac couldn't be possible cuz it's a proprietary thing. However, this is not a simple task for newbies.

That's not really cross-compilation in the traditional sense, but yes, if someone wants to tackle fully designing and implementing such a system for Flutter that's a possible approach.

-Stuart

michel...@gmail.com

unread,
Sep 3, 2019, 11:05:47 PM9/3/19
to Desktop Embedding for Flutter
Thank you again for the clarifications, information is always like honey.

"so I wouldn't worry about looking for them."
Okay, even tho I'm not very familiar with this Google forum platform. I feel a little lost in it. I had used before tho, but is confusing sometimes. Even with that simplicity. Anyway.


"I was explaining that 'flutter build' does the same thing." 
Perfect, but I was using the aforesaid tools just as a reference, in general, multiple tools like that are used in combination. But I get it.

"I'm afraid I don't understand what you think is unprofessional here."
This was about the "moving the built application to another machine" but I was (and still) aware that the FDE is in its early stage. I was just checking, who knows with all this kind of hype someone in the community already did something. Or started something.

"Flutter has the same core philosophies on desktop as on mobile."
Roger that.

"Please try to keep comments constructive."
Sorry, I didn't saw in that way. I wrote that part a bit as a joke - To break the ice, a little bit of humor. I know Google is huge, and Go is maintained by Go community and some Google engineers. And you've said, "substantial undertaking" in your first comment. I would swear that the " :P " would serve as a sign. :P

Alright. I'll keep on the eye around. Thank you again.

Cheers.

Reply all
Reply to author
Forward
0 new messages