-
-
Notifications
You must be signed in to change notification settings - Fork 71
chore: speed up engine builds with incremental namespacing #279
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
base: main
Are you sure you want to change the base?
Conversation
dc807dd to
78011ff
Compare
551aa61 to
63ded6d
Compare
3d00df6 to
5e741b8
Compare
|
I wonder if Briefly is handling Windows' file system properly. |
|
It does! It creates something like |
|
Maybe a file permission issue? I'm grasping at straws. This PR reads solid otherwise. |
|
Question, we don't need to namespace everytime during a normal release, correct? meaning you downloaded expert via a package manager, github releases, or are building a specific release from source. I think in that case, we don't need to namespace every time? Only the first time. In the case that we are working in development, we can maybe have an env var or just use mix env dev to namespace every time. I'll still review this tho. |
|
@mhanberg we need to do that for nightly since the engine builds are "namespaced" by the expert version(which right now is always 0.1.0) Even if we do that it's still beneficial to do incremental namespacing, it cuts down iteration time while developing |
|
Nightly should already have the commit hash appended to it. It's locally compiled releases that only have '0.1.0' |
this also allows us to avoid namespacing at all for published releases
0ca2621 to
0acdcb2
Compare
|
Ah, I didn't realize we do that to |
Drastically improves Engine load times by incrementally namespacing engine files
Rather than complicating the transformer modules to make them aware of which files should be touched and which shouldn't, we:
This achieves the same with the slight overhead of creating and cleaning up a temporary folder.
In my test on my m2 macbook I got the times down from ~10 seconds to 800-1200ms.