Skip to content
This repository has been archived by the owner on Mar 18, 2021. It is now read-only.

Support for AOT compilation #669

Open
sriio opened this issue May 7, 2019 · 62 comments
Open

Support for AOT compilation #669

sriio opened this issue May 7, 2019 · 62 comments

Comments

@sriio
Copy link

sriio commented May 7, 2019 •
edited
Loading

With Dart 2.3, you can compile your backend ahead of time but it doesn't work with aqueduct ...

Steps to reproduce:

Download Dart 2.3 here : http://gsdview.appspot.com/dart-archive/channels/stable/raw/2.3.0/sdk/

Create a new aqueduct project with aqueduct create test_project

Go to test_project and run dart2aot bin/main.dart bin/main.dart.aot

Problem:

You get this error :

 dart2aot bin/main.dart bin/main.dart.aot
error: import of dart:mirrors with --enable-mirrors=false

Cause:

Like the case of Flutter, the package 'mirrors' doesn't work with aot compilation ... No workaround, just find a way to replace it (with reflectable for example which is ok with aot)
@itsjoeconway
Copy link
Contributor

What would be the benefit of AOT compilation for an Aqueduct application?

@sriio
Copy link
Author

sriio commented May 7, 2019

Many :

  • Reduce memory (example : with an Angel application, before ~250mb after ~30mb)
  • Reduce startup time
  • Better performance overall
  • Easier deployement
  • Lighter docker image
  • ...

Documentation in relation : https://github.com/dart-lang/site-www/blob/a66d468245b84451aa40574db4ba81ee09bd9515/src/_tutorials/server/get-started.md#8-compile-for-production

@itsjoeconway
Copy link
Contributor

How does this compare to snapshotting? A simple, snapshotted Aqueduct app is showing up as 39.6MB of runtime memory usage.

What is the actual reduction in startup time? How is deployment easier? How is the Docker image 'lighter'? How is the overall performance improved compared to JIT for a long-running process like a server application?

@sriio
Copy link
Author

sriio commented May 7, 2019 •
edited
Loading

How does this compare to snapshotting? A simple, snapshotted Aqueduct app is showing up as 39.6MB of runtime memory usage.

Memory usage are similar between snapshot jit and aot. Maybe not the best argument.

What is the actual reduction in startup time?

App-JIT snapshot vs App-AOT snapshot : https://github.com/dart-lang/sdk/wiki/Snapshots

How is deployment easier?

No runtime, only dartaotruntime executable, your dart.aot and dart.aot.dill files (plus your assets if needed)

How is the Docker image 'lighter'?

Cause of previous point, we don't need google dart image (with runtime) and we can use alpine image for example (maybe scratch with some effort ?)

How is the overall performance improved compared to JIT for a long-running process like a server application?

Tests on my computer show me better performance overall for my simple REST API (response time, processing data). I don't have enough back to argue about long-running process (cause yes I know we loose one of the advantage of JIT on this point).

@itsjoeconway
Copy link
Contributor

I just fired up a snapshotted Aqueduct application and startup time was effectively instantaneous - I'm not sure applications that run for days/weeks/months at a time need a millisecond-order-of-magnitude improvement at startup.

Is deployment really easier? If you're containerizing, I don't see much of a difference here?

Is there a way to measure the size of a Docker image for an AOT vs. JIT compiled images? What are the actual savings quantified? Is there an example of this Dockerfile available?

In your performance testing, have you accounted for JIT? I'm not sure how runtime performance would be any different once the VM is warmed up. What are the actual tests & their measurements you are evaluating here?

@sriio
Copy link
Author

sriio commented May 7, 2019

Is deployment really easier? If you're containerizing, I don't see much of a difference here?

In my case, I containerize my app but maybe not everybody ...

Is there a way to measure the size of a Docker image for an AOT vs. JIT compiled images? What are the actual savings quantified? Is there an example of this Dockerfile available?

I created a sample angel application with 3 docker images (jit, snapshot & aot) (i'm using the official google dart image, aot use ubuntu image) : https://github.com/sriio/sample-dart-hello.

Building images :

docker build -f Dockerfile.jit -t sample-dart-jit .
docker build -f Dockerfile.snapshot -t sample-dart-snapshot .
docker build -f Dockerfile.aot -t sample-dart-aot .

Images size :

docker images
REPOSITORY                        TAG                            IMAGE ID            CREATED              SIZE
sample-dart-aot                   latest                         d68f6c7606a3        About a minute ago   117MB
sample-dart-jit                   latest                         8415ce919ec0        About an hour ago    637MB
sample-dart-snapshot              latest                         aa7545a373b6        About an hour ago    640MB

Stats :

docker stats
CONTAINER ID        NAME                       CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
8ceb16264950        sample-dart-aot-app        0.00%               16.81MiB / 1.934GiB   0.85%               788B / 0B           0B / 0B             2
e9775c0f7255        sample-dart-snapshot-app   0.00%               45.92MiB / 1.934GiB   2.32%               2.02kB / 0B         2.54MB / 0B         6
a59faf594521        sample-dart-jit-app        0.00%               131.9MiB / 1.934GiB   6.66%               2.2kB / 0B          2.38MB / 0B         7

In your performance testing, have you accounted for JIT? I'm not sure how runtime performance would be any different once the VM is warmed up. What are the actual tests & their measurements you are evaluating here?

As I said before, I don't have enough back to argue much more on performance. Dart 2.3 is not actually official, I only tested with my case (REST API without templating, etc ...). I can't give you full bench or other. Btw, compare VM warmed up (optimized only for some critical paths and after a huge? delay and amount of calls) against an aot build is not the best idea imo.

@itsjoeconway
Copy link
Contributor

The disk size of the image is significant and worth looking at. There is not a way to disable mirrors right now. We will look at solutions for producing AOT builds. Thanks for putting together the numbers.

@sriio
Copy link
Author

sriio commented May 8, 2019

Ok, good to hear.

I updated the aot docker image in my sample project. It's even better

docker images                                                
REPOSITORY                        TAG                                  IMAGE ID            CREATED             SIZE
sample-dart-snapshot              latest                               240ef99f0d4e        45 seconds ago      640MB
sample-dart-jit                   latest                               1a556a3f72fd        2 minutes ago       637MB
sample-dart-aot                   latest                               c36a0f6bd7d0        16 minutes ago      32.5MB

@listepo
Copy link

listepo commented May 23, 2019 •
edited
Loading

It would be great to have AOT compilation for the Aqueduct

@itsjoeconway
Copy link
Contributor

AOT for Aqueduct is currently under development.

@Hell0wor1d
Copy link

good job, thanks for sharing.

@dunsunik
Copy link

It's gone be a killer feature for us !
Thanks.

@itsjoeconway itsjoeconway mentioned this issue Jun 24, 2019
Closed
@itsjoeconway
Copy link
Contributor

itsjoeconway commented Jun 27, 2019 •
edited
Loading

Status update:

The first phase of this effort is complete. The effort removed all reflection from the framework and moved it to a separate runtime library (that is used by default when running your application).

The next phase will add a aqueduct build command that 1) generates a runtime library that doesn't use reflection specific to your project and 2) compiles an AOT build of your project that links to that runtime library instead of the reflection-based runtime.

The end result is that you'll be able to run/debug quickly using the same way you do currently (using reflection). When you are ready to ship, you will run aqueduct build and it will emit a single binary of your application. edit: The compiled binary will take the same arguments as aqueduct serve.

@WNemencha
Copy link

Hello, any news on this?

@itsjoeconway
Copy link
Contributor

Sure thing. Remaining effort:

  • Moving the runtime library generation out of Aqueduct into its own package; this is critical since safe_config is also mirrors-based and needs to provide its own runtime.
  • Creating tooling to generate runtimes and swap them in for Aqueduct test files; this is how we'll get to the same test coverage for mirror/generated runtimes.
  • Provide generated runtimes that pass tests

@WNemencha
Copy link

@joeconwaystk Ok, thanks for the update! Following this thread with lot of interest anyway. 👍

@lukepighetti
Copy link

hey @joeconwaystk thanks for the excellent support and hard work on aqueduct. looking forward to giving AOT a try on Cloud Run when its available

@noordawod
Copy link

Interested to move from Java to Dart on the backend, and Aqueduct came up as a leading choice.

Learning from past experiences, we're looking into no-reflection libraries only.

However, without AOT support (and killing reflection altogether) it's not going to happen unfortunateiy.

Could you share an update on development @joeconwaystk?

@benbarbersmith
Copy link
Contributor

@joeconwaystk, any update on the remaining effort from 18 August? I'm running some aqueduct backends on a few resource-constrained machines and the reduction in memory would be hugely welcome.

Thanks a ton for the awesome work already done so far on this overhaul!

@shinayser
Copy link

I am also interested on this.

@itsjoeconway
Copy link
Contributor

Thanks everyone for following up on this, it's clearly an exciting feature! I'll take a few moments here to outline some key things for you all to know:

In working through this effort, it was identified that a dependency of Aqueduct also used mirrors (safe_config). It was then determined that a more robust, cross-package solution was needed (package:runtime, see repo here). This package provides a generic solution for replacing all dependency packages that use mirrors with a code-generated variant. This package is under development and is generally functional.

Both package:aqueduct and package:safe_config require changes that are currently underway to use package:runtime. package:runtime still requires an additional mechanism that will allow packages to run their tests against a generated version of the package. This mechanism will then unlock the ability to run automated tests in CI against the mirror-based and generated variants of both aqueduct and safe_config. In turn, this will unlock the ability to validate the generated portions of Aqueduct/safe_config are accurate and complete this feature.

For the purpose of timing: currently, our company is growing significantly and we do not have much time to allocate to the efforts described above. This growth will provide us with greater ability to apply effort to Aqueduct. Additionally, the upcoming holiday season will free up some time as most of our customers are off during that period. I would expect that effort can be wrapped up late Q4, but don't want to make any promises as our organizational growth is critical in the long-term.

Thank you again for your interest in this feature, I am also looking forward to it!

@shinayser
Copy link

shinayser commented Oct 28, 2019 •
edited
Loading

Thank you again for your interest in this feature, I am also looking forward to it!

Great job @joeconwaystk! As the time goes on, dart gets even better. And few weeks ago, Dart just got a nice feature: support for creating self contained dart executables. That means, no dart sdk installation is needed to deploy dart projects, anymore! Check dart-lang/sdk#36915

Can't wait to see that on aqueduct!

@rota2000
Copy link

rota2000 commented Nov 6, 2019

Thank you again for your interest in this feature, I am also looking forward to it!

Great job @joeconwaystk! As the time goes on, dart gets even better. And few weeks ago, Dart just got a nice feature: support for creating self contained dart executables. That means, no dart sdk installation is needed to deploy dart projects, anymore! Check dart-lang/sdk#36915

Can't wait to see that on aqueduct!

me also. That will be great thing. Looking on Flutter, AOT code is running 4 or more time faster

This was referenced Nov 7, 2019
Open
Closed
This was referenced Dec 17, 2019
Closed
Closed
@mockturtl mockturtl mentioned this issue Dec 22, 2019
Closed
@DavidBernal
Copy link

Is it ready?

@itsjoeconway
Copy link
Contributor

The suffix .aot has no meaning here and, if you notice in the log, the executable is run directly.

As an update, there are about 10 tests failing now and they are all related to one function call.

@alexander-manley
Copy link

@joeconwaystk If you don't mind me asking, what would be that particular function call that is causing the 10 tests to fail? Appreciate all the great efforts so far!

@atik7
Copy link

atik7 commented Apr 13, 2020

from changelog
*Windows is not currently supported.

but "aqueduct build" working on windows 10, just need to rename executable to aot to exe

PS > mv .\web.aot .\web.exe
PS > .\web.exe
[INFO] aqueduct: Server aqueduct/1 started.
[INFO] aqueduct: GET /example 0ms 200

@itsjoeconway
Copy link
Contributor

Hi all. All of the tests are now passing. There is a pre-release available on pub (3.3.0-b1), but it some tricky package constraints have caused some issues with existing users of <3.2.1. Technically, you can run the build command once you have converted any relative path imports to package imports in files that require a runtime component (anything with a ManagedObject, ApplicationChannel, Controller/ResourceController).

@atik7 Good to hear on Windows. The mention in the CHANGELOG is there due to two things: the tests are not set up on Windows CI yet, and typically there are some path-related bugs that need to get ironed out.

You can install the beta version with pub global activate aqueduct 3.3.0-b1, but you'll have to pin the project's pubspec.yaml to that version (and update any relative imports).

@ScottHuangZL
Copy link

ScottHuangZL commented Apr 14, 2020 •
edited
Loading

Thank you for enable AOT and passing tests.

I just install 3.3.0-b1, and "aqueduct build" to compile a very simple entry project "try".
It successful generate a try.aot file in my Win10 machine.
I rename that try.aot to try.exe, and it is able successful run.

However, I only find "Server aqueduct/1 started", only 1 thread.
There will be 4 threads if I use "aqueduct serve" instead of run try.exe

Is it caused by beta version? Could you advise for it? Thanks.

@ScottHuangZL
Copy link

Oh, please ignore it, I can use "try.exe -n 4" to start 4 threads.
Thanks.

@benbarbersmith
Copy link
Contributor

benbarbersmith commented Apr 14, 2020 •
edited
Loading

Thank you so much for the amazing work on this, Joe. It's a fantastic ad for Stable Kernel. If you hired remotely, I'd be applying already. 👍

I just tried to use version 3.3.0-b1 from pub against an existing aqueduct project that can be served without issue on versions 3.2.1 and 3.3.0.

When running pub run aqueduct serve I get the following:

Failed to precompile aqueduct:aqueduct:
../../.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/lib/src/runtime/orm_impl.dart:117:24: Error: The method 'getDisplayString' isn't defined for the class 'DartType'.
 - 'DartType' is from 'package:analyzer/dart/element/type.dart' ('../../.pub-cache/hosted/pub.dartlang.org/analyzer-0.35.4/lib/dart/element/type.dart').
Try correcting the name to the name of an existing method, or defining a method named 'getDisplayString'.
                  type.getDisplayString()) ||
                       ^^^^^^^^^^^^^^^^
../../.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/lib/src/runtime/orm_impl.dart:118:16: Error: The method 'getDisplayString' isn't defined for the class 'DartType'.
 - 'DartType' is from 'package:analyzer/dart/element/type.dart' ('../../.pub-cache/hosted/pub.dartlang.org/analyzer-0.35.4/lib/dart/element/type.dart').
Try correcting the name to the name of an existing method, or defining a method named 'getDisplayString'.
          type.getDisplayString() == "Validate";
               ^^^^^^^^^^^^^^^^
../../.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/lib/src/runtime/orm_impl.dart:119:39: Error: The method 'getDisplayString' isn't defined for the class 'DartType'.
 - 'DartType' is from 'package:analyzer/dart/element/type.dart' ('../../.pub-cache/hosted/pub.dartlang.org/analyzer-0.35.4/lib/dart/element/type.dart').
Try correcting the name to the name of an existing method, or defining a method named 'getDisplayString'.
      final isInstanceOfColumn = type.getDisplayString() == "Column";
                                      ^^^^^^^^^^^^^^^^

It looks like getDisplayString was only added to type.dart in package:analyzer in commit eba38af5d13fb12a985a6ee42508f5da0017ea93 of dart-lang/sdk on 5 Dec 2019, so it won't be available in package:analyzer until at least v0.39.2.

So I think you need to update your version of analyzer in aqueduct's pubspec.yaml to something like >=0.39.2 before this will work.

I tried that on a local clone of this repo and it seemed to fix the issue. (I didn't notice any knock-on effects.)

@itsjoeconway
Copy link
Contributor

Both your aqueduct CLI an project's pubspec.yaml has to be version 3.3.0-b1. There is an issue with the pre-release on pub right now, but I have not had the time to correct it. Either way, this should probably get bumped to a 4.0 breaking change.

@benbarbersmith
Copy link
Contributor

Thanks for the fast response.

Both my aqueduct CLI and project's pubspec.yaml show 3.3.0-b1, so I'm not sure that's the cause:

$ aqueduct serve
-- Aqueduct CLI Version: 3.3.0-b1
-- Aqueduct project version: 3.3.0-b1
-- Preparing...
*** Uncaught error
    IsolateSpawnException: Unable to spawn isolate: ../../.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/lib/src/runtime/orm_impl.dart:117:24: Error: The method 'getDisplayString' isn't defined for the class 'DartType'.
 - 'DartType' is from 'package:analyzer/dart/element/type.dart' ('../../.pub-cache/hosted/pub.dartlang.org/analyzer-0.35.4/lib/dart/element/type.dart').
Try correcting the name to the name of an existing method, or defining a method named 'getDisplayString'.
                  type.getDisplayString()) ||
                       ^^^^^^^^^^^^^^^^
../../.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/lib/src/runtime/orm_impl.dart:118:16: Error: The method 'getDisplayString' isn't defined for the class 'DartType'.
 - 'DartType' is from 'package:analyzer/dart/element/type.dart' ('../../.pub-cache/hosted/pub.dartlang.org/analyzer-0.35.4/lib/dart/element/type.dart').
Try correcting the name to the name of an existing method, or defining a method named 'getDisplayString'.
          type.getDisplayString() == "Validate";
               ^^^^^^^^^^^^^^^^
../../.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/lib/src/runtime/orm_impl.dart:119:39: Error: The method 'getDisplayString' isn't defined for the class 'DartType'.
 - 'DartType' is from 'package:analyzer/dart/element/type.dart' ('../../.pub-cache/hosted/pub.dartlang.org/analyzer-0.35.4/lib/dart/element/type.dart').
Try correcting the name to the name of an existing method, or defining a method named 'getDisplayString'.
      final isInstanceOfColumn = type.getDisplayString() == "Column";
                                      ^^^^^^^^^^^^^^^^
  **** Stacktrace
  * #0      Isolate.spawnUri (dart:isolate-patch/isolate_patch.dart:494:14)
  * <asynchronous suspension>
  * #1      IsolateExecutor.execute (package:isolate_executor/src/executor.dart:60:23)
  * <asynchronous suspension>
  * #2      IsolateExecutor.run (package:isolate_executor/src/executor.dart:94:21)
  * #3      CLIProject.getChannelName (package:aqueduct/src/cli/mixins/project.dart:103:40)
  * #4      CLIServer.prepare (package:aqueduct/src/cli/commands/serve.dart:192:32)
  * #5      CLIServer.handle (package:aqueduct/src/cli/commands/serve.dart:85:11)
  * #6      CLICommand.process (package:aqueduct/src/cli/command.dart:159:20)
  * <asynchronous suspension>
  * #7      CLICommand.process (package:aqueduct/src/cli/command.dart:135:12)
  * #8      main (file:///Users/benbarbersmith/.pub-cache/hosted/pub.dartlang.org/aqueduct-3.3.0-b1/bin/aqueduct.dart:9:27)
  * #9      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:305:32)
  * #10     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:174:12)
  ****

But if there's an issue with the pre-release on pub, then I'll wait for now anyway.

Thanks again for the huge amount of effort you've put into this over the last few months. Seeing the aot version start-up instantly and run so quickly was very exciting. It will really help my docker-based deployments start quickly and keep memory use down.

@itsjoeconway
Copy link
Contributor

@benbarbersmith Just noticed your first comment and that you had mentioned working for SK remotely - this is something we are strongly considering now that Covid19 has tested us here and we have succeeded. I wanted to say I appreciate the comment you made, and apologies for not seeing it in my previous response.

In your particular case, the solution is to tighten up that analyzer constraint, yes. I'm just slammed this week - if someone pushed a PR to tighten the constraint, I can commit to pushing a new pre-release version to pub sometime this week.

@j4nk3e
Copy link

j4nk3e commented Apr 15, 2020

Thanks @joeconwaystk - this is amazing. I just built and tested with the AOT binary and everything works for me with the analyzer-hack. The startup time is stellar and now I can finally get rid of the dart runtime on the server.

This was referenced Apr 16, 2020
Closed
Merged
@nuriamp95
Copy link

What is the status of this? Thank you for the work

@sjapps
Copy link

sjapps commented May 17, 2020

I'm using this framework for a backend i'm writing. I've been following this thread and I'm hoping to launch my backend service with this. Please tell me this effort isn't abandoned!

@lukepighetti
Copy link

Not sure why people think this is abandoned... this is one of the best maintained backend packages I've ever seen.

@itsjoeconway
Copy link
Contributor

It's not abandoned, but it has certainly slowed down as we grapple with a post-Covid business landscape. This feature does exist in the 3.3.0-b1 release, but the dependency on analyzer caused issues with dependency resolution for non-prerelease users. I'd like to push a 4.0.0-b1 with this feature to pub this week.

@renlite
Copy link

renlite commented May 20, 2020

Why don't you use a builder (like json_serializable) for the ORM during dev-process. So it would be possible to start the server with >dart "appName" (JIT) or to compile the server with >dart2native + start. No more mirrors/reflections.

@dxps dxps mentioned this issue Jun 2, 2020
Closed
@dxps
Copy link

dxps commented Jun 2, 2020 •
edited
Loading

4.0.0-b1 update: on macOS (10.15.5), aqueduct build creates a working executable! ✨

$ aqueduct build
-- Aqueduct CLI Version: 4.0.0-b1
-- Aqueduct project version: 4.0.0-b1
Resolving ASTs...
Generating runtime...
Generated runtime at 'file:///{path-to}/heroes/build/generated_runtime/'.
Compiling package 'runtime'...
Package 'runtime compiled to 'file:///{path-to}/heroes/build/packages/runtime/'.
Compiling package 'aqueduct'...
Package 'aqueduct compiled to 'file:///{path-to}/heroes/build/packages/aqueduct/'.
Compiling package 'safe_config'...
Package 'safe_config compiled to 'file:///{path-to}/heroes/build/packages/safe_config/'.
Copying application package (from 'file:///{path-to}/heroes/')...
Application packaged copied to 'file:///{path-to}/heroes/build/packages/heroes/'.
Fetching dependencies (--offline --no-precompile)...
Finished fetching dependencies.
Compiling...
Generating AOT kernel dill.
Generating AOT snapshot.
Generating executable.
Marking binary executable.
Generated: /{path-to}/heroes/heroes.aot

Success. Executable is located at 'file:///{path-to}/heroes/heroes.aot'.
$

Very small size, instant startup time, fully working:

$ du -hs heroes.aot
7.2M	heroes.aot
$
$ file heroes.aot
heroes.aot: Mach-O 64-bit executable x86_64
$
$ ./heroes.aot
[INFO] aqueduct: Server aqueduct/1 started.
[INFO] aqueduct: PostgreSQL connecting, heroes@localhost:54322/heroes.
[INFO] aqueduct: GET /heroes?name=ap 48ms 200
[INFO] aqueduct: GET /heroes 4ms 200

@sjapps sjapps mentioned this issue Jun 9, 2020
Open
@agordeev
Copy link

Can aqueduct: 4.0.0-b1 be used as a dependency for Flutter project? I'm trying to use it, but still getting Dart Error: error: import of dart:mirrors is not supported in the current Dart runtime

@dxps
Copy link

dxps commented Jun 25, 2020 •
edited
Loading

IMO you cannot. And I don't even see it as a healthy approach.

That error is simply related to the fact that currently Aqueduct uses dart:mirrors, and during the AOT build it generates the artifacts (instead of doing the reflection at runtime). That is one of the main features of 4.0.0-b1 version.
Flutter and Aqueduct have different build processes.

Related to the need:

  • If you want to share some models (and logic), an external model lib might help.
  • Still, you may want to have the back-end and front-end sides totally independent, thus giving more flexibility and freedom.

@agordeev
Copy link

Ah, such a pity. Aqueduct ORM's Serialize doesn't integrate with json_serializable at all, so I thought I could use models on both sides.
It seems the only way is to implement toJson/fromJson on the client side manually, which is a huge drawback.

@Jonas-Sander
Copy link

Hey, I'm using local packages which I'm importing with path and getting this error:

*** Uncaught error
    Bad state: Bad state: 'pub get' failed with the following message: Because every version of [my_aqueduct_package] from path depends on [local_package_via_path] from path which is forbidden, [my_aqueduct_package] from path is forbidden.
So, because runtime_target depends on [my_aqueduct_package] from path, version solving failed.

  **** Stacktrace
  * #0      Build.getDependencies (package:runtime/src/build.dart:120:7)
  * <asynchronous suspension>
  * #1      Build.execute (package:runtime/src/build.dart:100:11)
  * <asynchronous suspension>
  * #2      BuildExecutable.execute (<data:application/dart>:13:259)
  * #3      main (<data:application/dart>:9:35)
  * #4      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:298:32)
  * #5      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:169:12)
  ****

This package is 2 directives up, so it is specified in pubspec.yaml like this:

  my_local_package:
    path: ../../my_local_package

Any help?

@7-Mav-7
Copy link

7-Mav-7 commented Jul 31, 2020

Hey, I'm using local packages which I'm importing with path and getting this error:

*** Uncaught error
    Bad state: Bad state: 'pub get' failed with the following message: Because every version of [my_aqueduct_package] from path depends on [local_package_via_path] from path which is forbidden, [my_aqueduct_package] from path is forbidden.
So, because runtime_target depends on [my_aqueduct_package] from path, version solving failed.

  **** Stacktrace
  * #0      Build.getDependencies (package:runtime/src/build.dart:120:7)
  * <asynchronous suspension>
  * #1      Build.execute (package:runtime/src/build.dart:100:11)
  * <asynchronous suspension>
  * #2      BuildExecutable.execute (<data:application/dart>:13:259)
  * #3      main (<data:application/dart>:9:35)
  * #4      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:298:32)
  * #5      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:169:12)
  ****

This package is 2 directives up, so it is specified in pubspec.yaml like this:

  my_local_package:
    path: ../../my_local_package

Any help?

Ran into this issue myself today, replacing the local packages with absolute paths in pubspec.yaml fixed it for me.

@maurobotta
Copy link

When will available 4.0 version (usable) ?

@jayjah
Copy link

jayjah commented Sep 28, 2020

Dart 2.9.2 and Aqueduct 4.0.0-b1 ist not compatible. The aqueduct build command crashed with the following error:

-- Aqueduct CLI Version: 4.0.0-b1
-- Aqueduct project version: 4.0.0-b1
Resolving ASTs...
Generating runtime...
*** Uncaught error
Bad state: Failed assertion: boolean expression must not be null
**** Stacktrace

Are you aware of these error? Do I have do downgrade dart to 2.8 to successfully build an aot snapshot of my server???

@BenjaminThong
Copy link

Dart 2.9.2 and Aqueduct 4.0.0-b1 ist not compatible. The aqueduct build command crashed with the following error:

-- Aqueduct CLI Version: 4.0.0-b1
-- Aqueduct project version: 4.0.0-b1
Resolving ASTs...
Generating runtime...
*** Uncaught error
Bad state: Failed assertion: boolean expression must not be null
**** Stacktrace

Are you aware of these error? Do I have do downgrade dart to 2.8 to successfully build an aot snapshot of my server???

Same issue with dart 2.10.2

@tusharsadhwani
Copy link

^ same issue with 2.10.3 and 2.11 beta

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests